TK.

Should work if you replace 0x80 by 0x8f, and 0x90 by 0x9f See this page for details about the MIDI protocol: http://www.midibox.org/dokuwiki/doku.php?id=midi_specification Best Regards, Thorsten.

Thanks for your work on the driver (I found it in the repository) Today I made a performance analysis for MIOS32_IIC - here the results: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fbenchmarks%2Fiic_access%2FREADME.txt Best Regards, Thorsten.

IFNEQ won't work with gputils anymore Replace the line by cpfseq MIOS_PARAMETER1, ACCESS rgoto USER_MPROC_NRE_NoNoteChn1 [/code] Best Regards, Thorsten.

Welcome back, Christoffer! :) Your questions are answered in detail here: http://www.ucapps.de/midibox_sid_manual_up.html and here: http://www.ucapps.de/mbhp_sid_old.html These are mainly quality improvements It's better to remove the oscillator, and to clock the SID module from the core. How you are doing this (via CORE:J10 or with a directly connected cable) doesn't matter. Without this modification, drum sounds could be triggered twice no (only required if MBHP_IIC_MIDI or similar IIC devices which require clock stretching are connected) Best Regards, Thorsten.

I will think about a solution how to integrate Mute groups and "simultaneous mute/pattern" changes into MBSEQ V3 Track buttons should do it as well? Because most MBSEQ frontpanels don't provide group buttons. It should also be possible to have Layer B as default selection in song page, but it will be a dirty solution. I only need to shift the cursor positions, so that the Song number will be selected as last item instead of first (Swindus: many code changes, should I really list them? Or should I change it directly which would consume less time at my side...) Best Regards, Thorsten.

Example: with J5_IO_Init(0x0f), J5.0..3 will be used as inputs, and J5.4..7 as outputs Best Regards, Thorsten.

Great customisation and impressive demo!!! :) The mp3 can now be downloaded directly from the server: http://www.midibox.org/users/rutgerv/SIDv2_demo.mp3 Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=12835.0[/iurl]

It also makes sense to ground the Audio INs of each SID, e.g. with jumpers connected to all J3_SIDx headers This should lower the noise floor dramatically! Best Regards, Thorsten.

fixed I replaced BankStick by "functions which get use of the IIC port" Best Regards, Thorsten.

no other functions In my own applications an ISR never accesses these pins Best Regards, Thorsten.

Yes, this feedback will cause an endless "upload request". Best Regards, Thorsten.

Works fine at my side Which MBSID release are you using? It could make sense to download the latest and to try it again (just to ensure, that you haven't changed the file somehow so that it is corrupted) Best Regards, Thorsten.

Just 30 minutes ago I fixed this bug, since I was able to reproduce it as well (but with MMJ only)! ;) -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fjava%2Forg%2Fmidibox%2Fmidi%2FMidiDeviceRouting.java Could you please beta-test this version: http://www.ucapps.de/midibox_sid/v2_editor/MBSIDV2_Editor_v0_2.zip Best Regards, Thorsten.

Works at my side with the latest editor release, and the improved version which is already in the repository. Maybe you tried to change the direction of an oscillator which isn't enabled? (check the waveform settings) It could also make sense to activate the oscillator link at the bottom of the editor. fixed in the docs Best Regards, Thorsten.

J4.SD is exclusively used by the IIC handler, while J4.SC is available on the LCD and J10 (application specific) port as well. This port is used by MIDIbox SID for example, according to the pin list, it's a class H pin RC4 and 5 are class G pins. It's used by some applications, but I guess that you will support a "safe mode" for mapping to shared pins anyhow? Best Regards, Thorsten.

Providing a MIDI preset page sounds like a good idea. Preset definitions could be imported from a .txt file, or entered directly. I thought it could be nice to enter labels with a dial code known from Mobile Phones with 12 GP buttons (e.g. GP2: abc, GP3: def, GP4: ghi, etc...) + delete/clear/enter/exit function Even an automatic text completion could be provided, known as "T9" ;) Best Regards, Thorsten.

See bottom of this page: http://www.midibox.org/dokuwiki/doku.php?id=book_reviews Best Regards, Thorsten.

Ok, conceptional changes: support for 16 tracks only a drum track consists of up to 16 instruments, stored in 16 layers in distance to a common track, each instrument has its own set of triggers (e.g. Trigger Layer A:Gate/B:Accent/C:Roll) each layer can store 2 additional values per step, mapable to velocity/CCs/PitchBender, and especially recordable (e.g. by tweaking the appr. GP encoders in live recording mode) To select a drum instrument, press&hold Layer C button - a special screen will be displayed, selection via GP buttons all layers can be labled with 5 characters all layers get an individual mute, but inside the common mute page you can also disable the whole track. number of steps (examples): 16 instruments per track, 3 trigger layers, 2 parameter layers: 32 (obsolete - concept has been simplified) 16 instruments per track, 3 trigger layers, 1 parameter layer: 64 (obsolete - concept has been simplified) 16 instruments per track, 3 trigger layers, no parameter layer: 128 (obsolete - concept has been simplified) 8 instruments per track, 3 trigger layers, 1 parameter layer: 128 (obsolete - concept has been simplified) note that each pattern consists of 4 tracks, and that 4 patterns can be played in parallel (e.g. depending on your prefered partitioning, you could configure 2 or 3 tracks for playing drums) [*]step view button (-> old MBSEQ frontpanel: F2) allows you to select the the edit view quickly [*]so long step view button is pressed, the A/B/C/D section can be selected via Track Buttons. This will also work for "common" tracks If somebody wants to try out the user interface: I can send you a MacOS based emulation .app ;) Best Regards, Thorsten.

No problem, the reason I started to ask users is to find out, if such changes would still work with their workflow. If they like the changes, or if it would lead to a cumbersome handling. Therefore just say what you think before it's too late ;) (I haven't started with the implementation of this part anyhow) Of course, this would be possible - but I prefer a solution which works for everybody. -> question to other users How many tracks/groups do you need? For my own workflow, the 4 existing groups are sufficient. Also 16 tracks are enough, considered that multiple drum instruments can be played from two or three tracks with the same "editing comfort" known from MB808 Best Regards, Thorsten.

In this page: You would press the button below D1 (if bass/snare/etc.. are played from these tracks) to mute/unmute the whole group. Take a second finger to mute/unmute another group. It's a question how you organize your songs. E.g., you could take D4 for some standard drums to bridge pattern changes. Normaly it would be muted - once you want to change patterns, mute G1-4 and D1-3, unmute D4, go to the pattern (or song) page, change the patterns, unmute G1-4/D1-3, mute D4 But I see your point with the "shift" button. Nice idea, could also be useful for synchronized pattern changes on all groups. Which button could be used for such a purpose - maybe SELECT, as it isn't used in the Pattern/Mute page yet? Best Regards, Thorsten.

All program change/parameter selections should be optional, and disabled by default Very similar to the way how such selections are handled in DAWs: Best Regards, Thorsten.

Thanks for your valuable input! :) As for the Mute page selection, I think that following approach would fit our needs: 5 Mute pages are required: 16 tracks for Group 1-4 and 4 * 16 tracks for Drum 1, 2, 3 and 4 These requirements can be covered by showing following page when the Mute button is pressed: Left hand side: gives you an oversight over the "track activities" (D1-D4 have to combine 4 tracks per meter), and the possibility to mute the complete group! Right hand side: allows you to enter a special mute page for a groups And it allows you to select a group w/o adding 8 group buttons to your MBSEQ frontpanel G1-4 (16 tracks) could be combined as known from MBSEQ V3: For drums, a separate page for each pattern will be required: Here you can also see the advantage of using labels (which will be available for Tracks as well) This handling isn't consistent to the configuration of "common" tracks. And it isn't selfexplaining - I guess that most people will prefer to see a more verbose configuration page - at the end, the time it takes to configure drum instruments could take longer with your approach, as we would need different pages to select the MIDI Note, Channel, MIDI Port and other Parameter assignments (which can be perfectly combined in a single page) I will use a similar layout like the 2*2x40 screen of MB808 E.g., gate and accent trigger are combined to a single character, which will give more space to display an additional parameter per step as well. :) Best Regards, Thorsten.

I like the idea to provide a copy function for instrument settings only. This should make it easy to adapt patterns. Note that we currently have 12 MIDI out ports (including USB), 4 AOUT ports (for 4 AOUT/AOUT_LC/AOUT_NG) modules) and 4 virtual busses static const seq_midi_port_entry_t in_ports[] = { // port ID Name { DEFAULT, "Def." }, { USB0, "USB1" }, { USB1, "USB2" }, { USB2, "USB3" }, { USB3, "USB4" }, { UART0, "IN1 " }, { UART1, "IN2 " }, { IIC0, "IIC1" }, { 0xf0, "Bus1" }, { 0xf1, "Bus2" }, { 0xf2, "Bus3" }, { 0xf3, "Bus4" } }; static const seq_midi_port_entry_t out_ports[] = { // port ID Name { DEFAULT, "Def." }, { USB0, "USB1" }, { USB1, "USB2" }, { USB2, "USB3" }, { USB3, "USB4" }, { UART0, "OUT1" }, { UART1, "OUT2" }, { UART2, "OUT3" }, { UART3, "OUT4" }, { IIC0, "IIC1" }, { IIC1, "IIC2" }, { IIC2, "IIC3" }, { IIC3, "IIC4" }, { 0x80, "AOU1" }, { 0x81, "AOU2" }, { 0x82, "AOU3" }, { 0x83, "AOU4" }, { 0xf0, "Bus1" }, { 0xf1, "Bus2" }, { 0xf2, "Bus3" }, { 0xf3, "Bus4" } }; [/code] It would be easy to provide a special mode which prevents that MIDI channels/ports and instrument settings/names are changed Best Regards, Thorsten.

Another request for comments: would you prefer the define the MIDI port, channel and name of your instrument inside each pattern (which will result into lot of editing effort whenever the instrument is plugged into another MIDI port, or assigned to a different channel, or you decided to use a different synth), or would you like to select a reference to a global instrument definition inside the pattern? If yes (and this is the main question): how many synth instruments, how many drum sounds should be definable? Would you like to store Program Change, Volume, and other CCs as well? Which ones? The instrument settings could be editable on the frontpanel, but also in a .txt file stored on SD card (so that you can change them with a text editor on your PC) Best Regards Thorsten.