TK.

before we drift into an academical discussion: Sauraean, I added the hooks into the MIOS32_SDCARD driver for you, so that you can experiment at application level w/o touching MIOS32 code. The change is available in the SVN repository, please update. MIOS32_SDCARD_SectorRead (and SectorWrite) now contain: // read 512 bytes via DMA #ifdef MIOS32_SDCARD_TASK_SUSPEND_HOOK MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, MIOS32_SDCARD_TASK_RESUME_HOOK); MIOS32_SDCARD_TASK_SUSPEND_HOOK(); #else MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, NULL); #endif so, once a function for MIOS32_SDCARD_TASK_SUSPEND_HOOK has been assigned, it will be called after MIOS32_SPI_TransferBlock. In addition, MIOS32_SDCARD_TASK_RESUME_HOOK will be called by the DMA callback In your mios32_config.h file, add following code: extern void APP_SDCARD_TaskSuspend(void); extern void APP_SDCARD_TaskResume(void); #define MIOS32_SDCARD_TASK_SUSPEND_HOOK APP_SDCARD_TaskSuspend #define MIOS32_SDCARD_TASK_RESUME_HOOK APP_SDCARD_TaskResume And somewhere in your app.c file: void APP_SDCARD_TaskSuspend(void) { // suspend task here } void APP_SDCARD_TaskResume(void) { // resume task here (will be called from DMA callback, it's an ISR) } Best Regards, Thorsten.

No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? In this case, I would expect that the same issue happens with older versions Best Regards, Thorsten.

No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? In this case, I would expect that the same issue happens with older versions Best Regards, Thorsten.

I assume that only a minority of applications need this. During SD Card transfers FreeRTOS will switch to other higher prio tasks automatically within 1 mS (preemptive multitasking is enabled). If you organize the task priorities accordingly, there isn't a problem with the blocking behaviour. E.g. I don't see a need for MBSEQ, MBNG, MBCV Best Regards, Thorsten.

Alright, so could you please try following pre-release at your side? -> http://www.ucapps.de/mios32/midibox_seq_v4_091_pre5.zip Changes: o Jam page: AStart now starts to record into first step in live recording mode (as intended), it starts on the selected step in step recording mode o Purpose of Record and Live Button & LED change: they switch between record (and live) mode w/o changing to the Jam page o new button/LED combo: JAM_LIVE and JAM_STEP: they switch to the JAM page and select Live resp. Step recording mode o removed obsolete (non-working) pattern based scale control as you can see, the Auto-start doesn't change the selected step in step recording mode anymore, because this causes more issues than it's worth to add workarounds into the code. I guess that you are sending CC#03 from a CC layer of a Note track. In this case, each step will send a CC independent from the gate, which means that you've to configure the correct scale value for each step of the CC layer, otherwise steps with value 0 will change back to 0:Major. If you are using a CC track instead, the value will only be sent if the gate is enabled. Best Regards, Thorsten.

This would be some kind of gateway to the SD Card; I agree that this would be the right choice for this use case, but the existing FILE->FatFS->MIOS32_SDCARD APIs couldn't be used for this purpose. Instead, a dedicated SD Card handler would be required which knows from which sectors the data can be read (or written). Actually very similar to the SD Card Sampler project: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2FSD+card+sample+player%2Fapp.c which caches the "file positions" and can read them via MIOS32_SDCARD_SectorRead The queue handling would require an alternative SDCARD_SectorRead function (implemented at application level) which uses the DMA callback mechanism as you described. The good thing: this dedicated handling doesn't require any change in existing drivers. And it's definitely the best choice performance-wise - if we ignore the fact that it requires some more code at application level (but this code could be "hidden" in a driver ;-) Best Regards, Thorsten.

No, this idea isn't easier, because the UI handler was originally implemented in a way that recording can only be done in the JAM page. It's available in the EDIT page due to some dirty tricks - actually it started as a try if this handling makes sense, and it seems that it was highly appreciated by the community (and I used it by myself as well :) As you report later, it's not working perfectly (poly mode not handled correctly anymore) Actually I would have to overwork the internal recording handling, the way how it's activated and routes incoming MIDI events. I've to check what this really means, currently I can only assume that I need the help from some beta testers to ensure that I haven't forgotten an important mechanism during the changes. Now where this fundamental change got a higher attention: who would like to attend the beta testing? (maybe I've some time for the change next week) The arpeggiator function isn't in danger, it's only a minor detail which doesn't work as expected by Jjonas while he intensively reviewed the MBSEQ functions, but there is no need to downstrip the chords for that reason. Best Regards, Thorsten.

The arpeggiator will take the last 4 played notes, which unfortunately means that on a 5-note chord, the first key of the chord won't be taken. It works at my side: Fwd on (which I somtimes call "live mode" because this was the original term) Play some notes on the keyboard, the should be forwarded. Now increase/decrease the Octave - the incoming notes should be transposed. Enable FTS: the incoming notes should be forced to scale. Enable Fx, enable (for example) the Echo effect, ensure that the sequencer is running: an echo should be played. Hm, I just looked into the code - actually an important piece is missing: the SCALE information won't be stored in the pattern, because it isn't available as a NRPN parameter. I think it would be better if I would just remove this feature. It's inherited from MBSEQ V3 (where I implemented it as an own idea) - but apparently nobody (including me) used it for MBSEQ V4 so far. Any objections? ;-) Best Regards, Thorsten.

No, I wouldn't provide a MIOS32_TaskSuspend function, but integrate an optional (#define based) call into the MIOS32_SPI module which would initiate the suspend for SPI transfers instead - similar to the way how I integrated Mutexes. You are asking specific questions where it would be easier for me to implement a generic change based on a prototype that you provide for your specific use case. Means: try to modify the current code until you are satisfied, explain your changes (don't commit them to the repository), and then we've a good basis for further discussions. This makes it much easier for both sides. Best Regards, Thorsten.

Hi, yes, there is a way to optimize the scan rate with a single core: just reduce the number of scanned DIN/DOUT registers. By default, up to 32 DINs and DOUTs are scanned, but if you reduce it to 16, 8 or even 4 (like MBKB), you can reduce the latency by factor 2/4/8 See also: http://www.ucapps.de/midibox_ng_manual_ngc.html (keyword: "SRIO") Best Regards, Thorsten.

Hm... so much text so late in the evening (and I already had to read so many topics today ;-) Are there any specific questions to me? Changing the firmware: some people find it simple, some others gave up - independent from their programming skills. There isn't so much documentation available about the MBSEQ firmware architecture and places where changes have to be done. There is also no documentation about "possible" and "impossible" features. A microcontroller is a very limited device, unlike a PC. You always have to keep the RAM consumption in mind. In addition, you've to check if the UI still allows the entry of additional parameters, or if an existing page has to be overworked, or a new page has to be created. People with good self education skills successfully added features in the past, w/o so much help from my side (which I can't give anyhow... ;-) Best Regards, Thorsten.

The reason is, that all MIOS32 sources (under mios32/) work independent from FreeRTOS; I don't want to introduce special FreeRTOS mechanisms there to simplify ports to other operating systems in future. Another reason is, that in my use cases I haven't seen the requirement to allow the execution of same or lower prio tasks if the tasks which loads/stores from/to SD Card is stalled. If you want to try this in MIOS32, please don't use "SAURAEN_DMA_TEST" as a switch, and don't call FreeRTOS functions directly. (if it's only a test, you wouldn't submit the changes to the repository anyhow...) instead use a generic names, similar to the way how I made the integration of Mutexes optional (search for MUTEX) Best Regards, Thorsten. P.S.: DIN/DOUT SPI transfers use the DMA callback hook - they are not waiting!

At least I added it to the wish list now, but I've to warn you: this will require some work, and might result into some unexpected issues which need to be solved. So, please don't expect a perfect implementation from the beginning. actually the entry of multiple loops only makes sense in conjunction with a BLM... Added it to the wish list. will allocate a lot of RAM. However, added to the wishlist for MBSEQ V4 Plus need more details to understand the request Is there really a difference compared to the current COPY/PASTE function? By holding PASTE you can move the block for which purpose? So, instead of transposing semitones, you would like to transpose the whole notes, and they should be displayed as 1/<octave>..7/<octave> - correct? I could add this as an option, but before I need to know, if this is the only change, or if variants are required. E.g. depending on the selected scale? Best Regards, Thorsten.

I've to check the issue that you've reported, it isn't intended. Unfortunately this is impossible - each track has only a single set of track progression parameters (including divider) You've to use a second track assigned to the same MIDI port and channel. Best Regards, Thorsten.

You are right. Track name isn't cleared as well, and the Program/Bank change commands are a new feature which (for me) belong to the general track configuration such as MIDI channel and port. Are you asking because you would like to improve the documentation, or because you request a change? The intention is to keep the basic track configuration, especially MIDI port, channel, event config, instrument selection (bank/program change), and everything else that I forgot. Yes, this part isn't documented well, but it's implemented to satisfy my personal use case. Hope that your manual will make it clear enough! :) I did this change ca. 4 years ago (renamed Stop to End, sequencer loops instead of stopping). Unfortunately changes where not properly tracked at this time, therefore I don't remember who requested this, and for what reason. I fixed the documentation. If there is a good reason for the "Stop", I could add this function, but apparently nobody missed it in the past. Added to the wishlist to improve the countdown, it shouldn't be so difficult and leads to more consistency The difference is, that you could unmute a track, and then the layers individually. This especially makes sense on drum tracks, but also for CC tracks Make sense, added to wishlist There is currently an open request for providing a dedicated Rec button for Step and Live recording mode. A possible enhancement of this button function would be, that the first push just changes to the Jam page, and an additional push (resp. whenever we are already in the Jam page) will enable/disable the recording function. Does this make sense? added it it should only be sent if the value has changed (similar to CCs) yes, we have this risk. In addition it make sense to highlight, that most synths can't process a program change immediately, resp. there could be an audible delay of following note events. This feature will only work properly with synths which can change the patch in "zero-time" added to the wishlist to clarify this issue (I remember that the implementation of this EDIT capability wasn't straightforward, will need some work to improve it) This is no bug, but a conceptional limitation. The arpeggiator had always only 4 key slots (already in MBSEQ V2), this can't be changed anymore. And the arpeggiator isn't directly related to the chord function. The support for chords with more than 4 notes is pretty new, but it's impossible to enhance the arpeggiator as well, especially since this would change the arp step configuration (-> incompatible legacy patterns) They should have an effect in live mode I've to check under which conditions the track will be retriggered Short delays don't surprise me, because the change is synchronized to the next step No, the assumption is wrong. Use case behind the pattern based control: somebody wants to switch the root and scale with a pattern. The pattern could also contain the loopback track(s) for Bus1..4, so that it's possible to switch the transpose/arpeggiator lines + root note + scale with a single pattern change in the PATTERN page. Yes, this is how the root note is working Note that "Keyb" could also be the loopback track which sends to Bus1 CC#0..CC#127 So, all possible "standard" CCs Best Regards, Thorsten.

I'm using a PICkit2 meanwhile, see also: http://www.ucapps.de/mios_bootstrap_experts.html And I'm a Mac user. The PICkit2 programming software can be started under Windows in a VirtualBox, but there might be better solutions for the case that you've no Windows VM running yet... Best Regards, Thorsten.

I could try to analyze the issue with this card. @Karg: I noticed that you live in germany - would you like to send me the card? Best Regards, Thorsten.

One input can be assigned to many functions, but it isn't possible to assign a single function to multiple inputs. Best Regards, Thorsten.

Which CC is sent by the footcontroller? Best Regards, Thorsten.

Clever idea! Added to the wish list (sending a permanent note to all MIDI and AOUTs, toggle function) Best Regards, Thorsten.

Hi Rowan, this is a typo in the documentation: 3.3V outputs are only available for MBHP_CORE_LPC17 due to a chip limitation (erratum). MBHP_CORE_STM32 and MBHP_CORE_STM32F4 configure the output pins in open drain mode, which means that the pin is in high impedance state if no MIDI message or a logic-1 is sent. Via the 220 Ohm resistors and the optocoupler at the receiver side, the voltage level will be pulled to ca. 4..5V. The MBHP_MIDI_IO board has an additional 100k pull-up resistor to 5V, but this one is only used to ensure a proper signal for the LED indicators. Best Regards, Thorsten.

Hi Xavier, interesting that somebody still builds a MBSID V1 :) For the DEFAULT_BS_TYPE == 1 configuration, address selections A0, A1, A2 and A3 are used. A4-A7 are not addressed. Best Regards, Thorsten.

I take this as a reminder. As you can see, solving this issue isn't so easy, it already resulted into two intermediate updates and still doesn't work perfectly :-/ The name is inherited from the MBSID which has a "303-style sequencer" as well. So, yes it refers to the TB-303 bassline synth, resp. the way how this device allows to enter sequences (key, gate, glide, octave up/down) yes Yes, this page can only be selected with a dedicated button or a bookmark. It doesn't make much sense in the menu page (too cumbersome usage) - of course, if somebody requests it, I could add it there. Not so nice, I will change this, so that the last remaining track can't be deselected. If enabled, all track parameters will be cleared. Exception: MIDI port and channel. I don't really like such a temporal, "timed" handling, because it is error prone. And by introducing such an handling for a certain button, I'm sure that the next users would request "doubleclicks" or similar functions for other buttons as well - it just doesn't fit to the general concept of the UI I don't find the current handling so bad - it's easy to learn (and we've already some videos which show how to use it, no? ,-) Best Regards, Thorsten.

Ok, I will check this - added to the wish list added to the wish list as well no, this isn't normal Would it be possible to try it with a different SD Card (e.g. from a different vendor) just to doublecheck if the problem is located somewhere in the HW wiring, or to a compatibility issue? Best Regards, Thorsten.

Well written! Configuration means all configuration parameters except for MIDI port and Channel A list of configuration parameters can be found in the CC implementation chart: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fdoc%2Fmbseqv4_cc_implementation.txt yes Best Regards, Thorsten.