TK.

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.

Super! :) Ja, das IIC_MIDI Modul laesst sich auf der Event Seite (MENU->Evnt) als alternativen MIDI Ausgang selektieren. Bis zu 4 IIC_MIDI Module koennen auf diese Weise addressiert werden. Gruss, Thorsten.

Oh, the answer to this question was too obvious: of course, all AOUT modules will be supported. It will even be possible to chain the modules in order to enhance the number of channels. Best Regards, Thorsten.

These are timing constraints which usually have to be measured with a scope, because there are too many parameters which affect the slew rate (e.g. cable length, input impedance of the target device), not only the one specified in the PIC datasheet... Best Regards, Thorsten.

"hex´n" ist eine lustige Wortschoepfung, leider funktioniert sie nur im Deutschen, ansonsten wuerde ich glatt das Wording auf den ucapps Seiten aendern ;) Zu Deinem Problem: wahrscheinlich wurde der PIC mit der ID "0000000000000000" gehext, so dass MIOS defaultmaessig ueber den MIDI Out des Core Moduls sendet. Die ID laesst sich nachtraeglich aendern, doch die Prozedur muss ich glaube ich gar nicht erst erklaeren, weil sie bei neueren PIC18F4620 obsolet ist (*) - der EUSART Bug wurde mittlerweile gefixed. Somit wuerde ich vorschlagen, dass Du einfach den MIDI Out Port des Core Moduls zum hexn verwendest. Gruss, Thorsten. (*) change_id Applikation, iic_midi_10.hex aufladen

Yes, it should be removed from the skeleton. I remember again, why I didn't removed it by myself: the .asm file is a wrapper, which shouldn't touch the original definitions in .inc to ensure, that I'm able to use the module in assembly only applications with the same behaviour. It was the only way to ensure, that the original default value defined in .inc still will be taken w/o overruling in .asm It's like an advanced consistency check. If somebody changes the default value directly in the .inc code (for whatever reason, normaly the source code shouldn't be touched), the compiler will fail due to the missing _blm_button_debounce_delay variable So, he needs to search for the error, and will find out, that the same definition is used in .asm as well. no, it isn't, since you cannot include the file before variables are declared However, no need to discuss the sense and nonsense about this trick here. I found it useful for a particular issue, but if you don't see the need - don't use it! Best Regards, Thorsten.

I guess that you mean the "trick" in the blm module, which I used for BLM_NO_DEBOUNCING in blm.asm It isn't really required, and as you can see in blm.inc, a common "#ifndef/#define" combination works as well. I was only so annoyed by this GPASM limitation, that I documented a possible workaround for the case I ever need it ;) Best Regards, Thorsten.

You could use a PIC based MIDIbox CV, connected to a MIDI port (e.g. GM5 based) However, keep in mind that the user interface of the emulated MBSEQ is not designed for computers. You can move encoders with the mousewheel, and click on the buttons with your mouse or with the keyboard - but the usage of a real MBSEQ will always be more intuitive and faster. The purpose of the MacOS based emulation is mainly to provide a virtual prototype, which allows people to get a better understanding about the possibilities of a certain application before building a MIDIbox, to plan a customized frontpanel, and for programmers to debug an application w/o the need for ARM debugging tools. I consider to provide a special MIDI remote function, which will allow a PIC based MBSEQ to control an emulated MBSEQ V4 for those who don't want to replace their core module by a MBHP_CORE_STM32 yet. The remote connection could also allow to control AOUTs and triggers. LCD output should be feasible as well. Even running it on a Windows or Linux PC should be possible this way w/o much effort at my side. But for myself it's a minor feature, therefore: low priority Best Regards, Thorsten.

In order to enable this feature, you have to apply svn propset -R svn:keywords "Id" <filename(s)> to your files Thereafter, add "$Id: $" to the header (or wherever). It will be automatically updated on each commit Advantage: release packages will contain a reference to the svn revision you were using Best Regards, Thorsten.

Today I reached an important milestone in my "feasability study" (see initial posting) Most of the MBSEQ V3 features are now implemented on C, they are running on STM32 and they are accurately emulated under MacOS. The code size is currently 80kb, compared to 64kb PIC code of MBSEQ V3 this means, that the code density of the ARM Cortex M3 processor is almost equal for a real world application. 432kb flash memory is unusued yet - a lot of room for future enhancements! It's possible to use 16 tracks with 256 steps, 4 parameter layers, 8 trigger layers. Paritioning is customizable, which means, we could also use 16 parameter layers with 64 steps (-> 4 measures) for polyphony in a single track. But this doesn't really load the STM32 chip, nothing speaks against the usage of 32 or 48 tracks (e.g. 32 additional tracks for percussions, which consume much less RAM than fullly featured tracks) The most important thing - and this was the point which really scared me, as it required a lot of pre-work: loading a complete pattern from SD Card takes only 7 mS in worst case. And even if multiple patterns are loaded for different track groups in song mode, it won't affect the sequencer timings, as MBSEQ is now working with a MIDI event scheduler in a separate high priority task which ensures super stable timings while patterns are loaded or stored. The sequencer is clocked at 384ppqn in master and slave mode, which is 16 times the normal 24ppqn MIDI clock resolution. I haven't noticed any robustness issues yet, but I must also say, that I haven't made songs with MBSEQV4 yet - programming this beast is too much fun! ;) A MIDI file player is already implemented as well. It will be possible to import/export patterns via .mid files, as there is more than enough flash memory free for such features. Due to the dramatically increased pattern size, BankSticks won't be supported anymore. Instead a SD Card is required, which is much faster and more comfortable to use anyhow (e.g. for exchanging files, or to create backups) The bank format is flexible enough to cover different track partitionings and future enhancements. A bank consists of 64 patterns, and takes 368674 bytes. The number of available banks isn't really limited, so you can take different banks for different purposes (e.g. different banks for different MIDI devices and/or music styles), and sort your setup this way. All banks/patterns/tracks can be named with 20 characters. Thanks to the new "freedom" in memory size/CPU speed and C language, certain features which seemed to be impossible for MBSEQ V3 were a really no-brainer for MBSEQ V4. Like the "Echo Fx", which was completely programmed in two hours, and worked almost immediately w/o much debugging effort... ... which brings me to the conclusion, that it cannot take so long until MBSEQ V4 is ready for an alpha release - for those who own a Mac: you will be able to try it out immediately. ;) Status MBHP_CORE_STM32 module: I will get a second batch of 25 prototypes in ca. 2 weeks, they are already assigned to forum users with programmer status. It will be released if there are no errors anymore. Upload via MIDI is already possible, so that there is no need for a JTAG programmer, considered that somebody (like Smash) pre-programmed the chip. But there are also inexpensive solutions to program the bootloader with a common RS232 interface. Once this has been done, code can be uploaded via USB (which works btw. even faster than JTAG). More about this topic sooner or later in another article. Best Regards, Thorsten.

No, it isn't - can you confirm that this only happens for G4? Then it's a strange bug Any hint on which line I can try to fix it? ;) Best Regards, Thorsten.