TK.

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.

Each drum instrument will provide a dedicated parameter layer, which is usually assigned to velocity, but could also be assigned to Pitch Wheel. The number of available layers depends on the number of steps per pattern For "common" patterns A/B/C/D sections could be provided as well, but this means that I cannot use the track buttons anymore to select the section (-> inconsistent UI) Best Regards, Thorsten.

Both, MIDI channel and MIDI port can be defined for each instrument (256 ports are available, each port provides 16 channels). 16 ports (-> 32768 CV channels and triggers) are prepared for AOUT outputs, we've also some ports for USB, UART, IIC, OSC and future extensions - this should be sufficient? ;) Don't worry about the improved real time recording. Programming this in C with the already available infrastructure (FreeRTOS and MIOS32) is pretty easy and much less time consuming than implementing the same stuff in assembly language with all those PIC limitations as mentioned several times before. Best Regards, Thorsten.

This question is mainly directed to people who already built a MBSEQ, and know the current user interface. While thinking about the most erconomic way to handle additional percussion tracks in MBSEQ V4, I came to the conclusion that a MB808 like solution would be the best (-> background infos) If you haven't tried it yet: just upload the setup_808_mbseqv3_hardware.hex file of the midibox_808 package - BankSticks won't be reformatted, therefore you can evaluate this version w/o the risk for data loss. Main difference compared to a common tracks: - 16 percussion instruments are combined in a single pattern. In MBSEQV4, I could provide 4 percussion groups, which results into 64 additional tracks played in parallel to 16 "full featured" tracks used for synths and loopbacks - this would allow to prepare some "base" patterns (e.g. bass drum, snare, hihat), and some additional patterns with other percussions/samples which are added during the session to fill the song. - a A/B/C/D section to select variants/breaks. These sections can also be chained (e.g. press A/B to combine two sections) - A/B/C/D would be selectable with the 4 track buttons - simplified live recording of all percussion instruments - and also a live play mode to play drum instruments with GP buttons - all drum instruments can be named - etc.. (see manual) Alternatively to such a solution, I could integrate a percussion option for 16 drum instruments to a common track normaly used for synth instruments, which would result into 4 tracks * 16 instruments = 64 instruments per pattern group (=256 instruments in total, splitted over 4 groups when no synths are played) But I fear that it will complicate the UI too much, especially because they would be combined to a single pattern (instead of 4), and the track buttons couldn't be used to interactively select the A/B/C/D section. Instead, if I would clearly separate "synth" from "drum" tracks by providing different groups (G1..2..3..4 for synths, G5..6..7..8 for percussions) I hope that the usage will be easier. How do you think about this? Any alternative proposals? Best Regards, Thorsten.

Yes, for MB808 it will work this way. For MBSEQ it won't (but the appr. SEQ_BUTTON_* functions are already available) There will be a minor issue if you access CS_M_UTILS functions directly: the function will be triggered when the button is pressed *and* depressed. However, probably you will never notice this ;) Best Regards, Thorsten.

Ok, found the bug :) The bugfix is already available in the repository. At the end (after adding some more comments), it turned out that the issue was caused by a single line of code: Wrong: ;; don't save if cursor pos >= 7 movlw 0x06 [/code] Correct: [code] ;; don't save if cursor pos >= 7 movlw 0x07 Note that the comment already gave me a hint about the intended boundary ;) Any other issues before I'm doing a new release? Best Regards, Thorsten.

Both (it also affects MIDI notes) Best Regards, Thorsten.

In main.inc, USER_Init muss folgendes hinzugefuegt werden: ;; perform additional display initialisation for DOG display movlw 0x39 ; 8bit interface, switch to instruction table 1 call MIOS_LCD_Cmd movlw 0x1d ; BS: 1/4, 3 line LCD call MIOS_LCD_Cmd movlw 0x50 ; Booster off, set contrast C5/C4 call MIOS_LCD_Cmd movlw 0x6c ; set Voltage follower and amplifier call MIOS_LCD_Cmd movlw 0x7c ; set contrast C3/C2/C1 call MIOS_LCD_Cmd movlw 0x38 ; back to instruction table 0 call MIOS_LCD_Cmd movlw 0x0c ; display on call MIOS_LCD_Cmd movlw 0x01 ; Clear Display call MIOS_LCD_Cmd movlw 0x06 ; Entry Mode call MIOS_LCD_Cmd [/code] Das Cursor Mapping in Deinem setup_*.asm File wie folgt konfigurieren: [code] ;; number of LCD lines (supported: 2 for 2x* LCDs and 4 for 4x* LCDs) #define DEFAULT_LCD_LINES 2 ;; LCD line -> cursor offsets #define DEFAULT_LCD_LINE_Y0 0x00 #define DEFAULT_LCD_LINE_Y1 0x10 #define DEFAULT_LCD_LINE_Y2 0x20 #define DEFAULT_LCD_LINE_Y3 0x30 Du koenntest auch mal "DEFAULT_LCD_LINES 3" ausprobieren, ich bin mir jedoch nicht sicher, ob es funktioniert. Habe es noch nie ausprobiert. Gruss, Thorsten.

Hi, yes, the 2 gate outputs of the AOUT module are always serviced. With: #define DEFAULT_J5_FUNCTION 3 in your setup_*.asm file, you will get access over all 8 exernal switches at CORE:J5 Best Regards, Thorsten.

I already added it, just press the refresh button of your browser But this is no CC parameter chart, because the parameters are accessible via NRPN, and via various modulation sources. Again - this was the initial question: It seems that some people would prefer to automate MIDIbox SID V2 parameters with CCs instead of NRPNs due to DAW limitations. Although CCs are limited in the number (only 128) and resolution (only 7bit), they could still cover your usecase... ...so, just list the parameters you would like to control and I will add a CC mode which will fit your needs. Addendum: currently following CCs are allocated CC#00: select Bank CC#01: Knob#1 CC#06: NRPN MSB Value CC#16: Knob#2 CC#17: Knob#3 CC#18: Knob#4 CC#19: Knob#5 CC#38: NRPN LSB Value CC#64: Sustain CC#89: NRPN LSB CC#99: NRPN MSB I will add this to a new text file later, and release it in the SVN (no need to write a second documentation in the Wiki, which will be inconsistent whenever I'm doing changes) So - which parameters would you like to control directly via 7bit CCs? Best Regards, Thorsten.

I deleted the .txt file on uCApps, as it isn't guaranteed that it will be updated. The SVN link is the only one which is almost up-to-date Probably some of you already noticed, that this file is in the doc/ directory of the release package as well. Some words to the Wiki page: it's somehow unsorted (MBSID V1 mixed with MBSID V2) And sometimes you are writing it wrong - it's neither called "Midibox Sid", nor "mbSID", it's either "MIDIbox SID" or "MBSID" However, it seems that nobody is interested on an alternative CC map to access a selection of parameters directly? Best Regards, Thorsten.

http://www.midibox.org/forum/index.php/topic,12774.0.html

It seems that some people would prefer to automate MIDIbox SID V2 parameters with CCs instead of NRPNs due to DAW limitations. Although CCs are limited in the number (only 128) and resolution (only 7bit), they could still cover your usecase... ...so, just list the parameters you would like to control and I will add a CC mode which will fit your needs. Here a list of all parameters: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_parameter_chart.txt Best Regards, Thorsten.

Du meinst ein DOG Display? Es wird ein paar (kleinere) Quellcode-Aenderungen erfordern, da es nicht 100% kompatibel zu den HD44780 Displays ist - so liegen bspw. die Cursor-Addressen fuer Zeile 1/2/3 bei 0x00/0x10/0x20 statt 0x00/0x40/0x80, und die LCD Initialisierungssequenz muss erweitert werden. Probleme wird es auch mit den 16 Zeichen pro Zeile geben, denn die Erweiterungen fuer Zeile 3 und 4 habe ich fuer ein 20x4 Display auslegt. Du wirst also die 4 fehlenden Buchstaben schmerzlich vermissen... Gruss, Thorsten.

If you want to join the second prototype order: there are still three boards left: http://www.midibox.org/forum/index.php/topic,12658.msg106948.html#msg106948 I cannot really say, which solution is better, as I don't know the capabilities of dsPIC. STM32 has 64k internal RAM, which can be used for buffering between the DMA based I2S output routine (MIOS32_I2S is running in background and doesn't load the CPU), and the SD card, which stores the samples. MIOS32_SDCARD is DMA based as well - typical transfer rate is 8 MBit/s Sufficient? The CPU is clocked at 72 MHz, and can do a lot of calculations while data is transfered from SD Card into RAM, and from RAM to I2S in background. However, an ARM Cortex M3 is not a DSP. But it has a floating point unit... and it can be used for so many other purposes :) The DMA access doesn't support true random access. Data has to be moved into the sample buffer, so that it can be streamed to the I2S chip in background. So, your application still has to prepare the stream before the DMA takes it over. This method has the advantage, that the CPU doesn't need to service the I2S chip in realtime (at a given sample rate), but that it can do many other tasks in parallel. I think: yes no (/edit: fixed inversion issue ;)) The reason why the example doesn't cover your feature list is not, that the STM32 isn't capable of doing this. It's mainly because I wanted to keep it simple to give other people (who are interested in programming a sampler or wavetable synth) a starting point. Best Regards, Thorsten.

Sounds nice. For the case that you would like to do some experiments with STM32 later: here is the i2s_synth example Best Regards, Thorsten.