m.str

Thanks for sharing your experiences on this. I think it's kind of comforting to know that the dump reception from a synth might be problematic in general, though it obviously does not solve both of our problems :) Another unfortunate realisation came to me after I had reduced the syxdump_pos-listening EVENTs by half. It did not have any apparent effect on the Input Buffer Overflow, the stream was cut at the same position as before.

I might be too late to join this thread, but I am currently running a setup, that seems similar to your project regarding large SysEx Dumps and multiple RECEIVERS/SENDERS listening to a received dump. Right now I am quite confused on how your up-to-4000-Bytes-long dump can actually, under certain circumstances, be received correctly. The dumps I request from my Hardware Synths are "only" 90-850 Bytes long and there is ALWAYS a certain point of cut-off, whereafter all remaining bytes get lost and the listening EVENTs are being initialized with a value of 0. And of course I always traced back my SysEx-related problems to two facts: a) the number of Events listening to syxdump_postitions is too high (the Encoders of my hardware MIDI controller need to be initialized with syxdump_pos values, a whole set of encoders consists of 64 Encoders minimum, switched on/off with the banking mechanism so a total of 32 Encoders should be active at once) -> Each Encoder requires two Events listening to the same syxdump_pos though.. And yes, this results in what TK has mentioned, I am having repeated notifications on timeout problems, always on the MIDI IN ports where the incoming dumps sent by the hardware synths come in. b) On the other hand I was always assured that SysEx messages that huge could NEVER be processed in total, because of the Input Buffer Limitations and the resulting bottleneck issues. Before reading this I was actually about to ask if there is a nice way to priorise the Reception of a Sysex Stream until the 0xf7 has arrived, meaning that even if the maximum buffer size has been filled there could somehow be a workaround with priorising the Reading of these large SysEx files (at least until some other break statement has been reached..) Maybe something in the likes of this: https://github.com/midibox/mios32/tree/master/apps/tutorials/025_sysex_and_eeprom But since you could progress with your giant dumps I came to the conclusion, that the main problems really are the listening events and they seem to causes severer problems.. Is that correct? How did you get along with your project, did you find a way to re-incorporate the listening events? Greetings, Micha

And yes you are right, that was totally unnecessary. I probably copied that by mistake from the line above

Hello Zam, my response comes a bit delayed, because I did some further inspection on the error, since I found out, that this was not the only NGC/NGR-file complex where an error like that happened. Furthermore I realised, that this repetitive CC message behaviour did not just occur after switching banks (and therefore calling different sections). I found out, that the CC number for Bank LSB was just coincidental in that case. In another script the same kind of repeating CC messages occurred with other CC numbers. What I found out was that .. a) Those were all Messages sent to the LED rings of my hardware controller --- the rings surround 32 Encoders; each ring is adressed by a different CC number, hence the different CC numbers in the different scripts. In the example from the earlier post there was only one LED ring where this happened, which coincidentally had the CC number which is usually standard for Bank LSB b) this ONLY happened when the correlating EVENT-* Objects were parametrized as "bank=0", which basically happens in all of my setups. c) There is an extensive misbehaviour of those LED rings while MIDI OX is open. Once closed, the rings are back to normal behaviour. The unfortunate thing about this, is that it did not explain my original error of the repeatedly resetting MIDI controller. But the two problems do not seem to affect each other.

Hello, I just noticed a peculiar error in my configuration, that is based on the way that I switch banks while running the application. On my hardware controller I have two designated buttons, whose purpose it is to increase or decrease the bank number respectively. Basically it works as desired, the bank numbers get changed accordingly. But when I use these buttons multiple times, especially in succession to another, I noticed that my MIDI controller "resets". It return to its startup screen, but keeps continuing to react to my bank selections. This seems like an overload of some kind. Because I did not notice any curious in the MIOS terminal I decided to take a look at it in MIDI OX. There I saw, that after triggering one of the bank switches a loop starts which repeats a bank selection command over and over again. As if the triggering by my hardware controller does not get stopped after adjusting the bank number. The peculiar thing about it is that the value for the bank selection is 0x76, which is 118 in decimal format. That does not make any sense to me, unless it is some kind of error code, which I do not know about. Here is a picture of the log: the 0x02 values is te bank number value set by me triggering the respective button, the 0x76 lines just keep goin on and on after that. i was also wondering about the SysEx message, but I think it might be one of the logs ("bank == 2") that I set up in the ngr script to be printed after bank switching. The relevant ngc code for this is: #Bank Selectors EVENT_RECEIVER id=4042 fwd_id=SENDER:4042 type=NoteOn key=0x0a chn=1 range=0:1 EVENT_SENDER id=4042 if_equal_stop_on_match=RECEIVER:4042:1 type=Meta meta=IncBank meta=RunSection:2 EVENT_RECEIVER id=4043 fwd_id=SENDER:4043 type=NoteOn key=0x09 chn=1 range=0:1 EVENT_SENDER id=4043 if_equal_stop_on_match=RECEIVER:4043:1 type=Meta key=0x09 chn=1 meta=DecBank meta=RunSection:2 The ngr code for that section: if ^section == 2 log "section 2" if ^bank == 1 log "Sec 2 Bank 1" send SysEx OUT2 0xf0 0x42 0x30 0x24 0x41 0 0 0x00 0xf7 elsif ^bank == 2 log "Sec 2 Bank 2" send SysEx OUT2 0xf0 0x42 0x30 0x24 0x41 0 1 0x00 0xf7 elsif ^bank == 3 log "Sec 2 Bank 3" send SysEx OUT2 0xf0 0x42 0x30 0x24 0x41 0 2 0x00 0xf7 elsif ^bank == 4 log "Sec 2 Bank 4" send SysEx OUT2 0xf0 0x42 0x30 0x24 0x41 0 3 0x00 0xf7 elsif ^bank == 5 log "Sec 2 Bank 5" send SysEx OUT2 0xf0 0x42 0x30 0x24 0x41 0 4 0x00 0xf7 endif exec_meta RunSection:1 endif Does this seem familiar to anyone? Any reply much appreciated here! Best, Micha

Are you talking about the NG LCD display? If so, I can not tell for sure because I use displays on other MIDI hardware controllers.. But there it works. Add the bank=x parameter to the designated EVENT_* commands and that should be it actually

Hey, have you tried using different banks? And then activating/deactivating parameter modification depending on bank settings?

Hey Zam, Okay thanks for the clarity, I see now that this is not applicable to my case, as I am always dealing with hardware synths/controllers on both sides of the configuration chain. To be honest I do not really trust my own capabilities enough to do this and I kind of have a deadline on my project, so I guess I will have to exclude that idea... Actually yes. I do have some test scripts, that I use to test knob behaviours on my hardware controller. Those scripts only initialize one or two of the encoders for parameter change and therefore only read one or two positions of the SysEx dump. I do not get the timeout message there. Thing is, I do not think I can reduce the IO load in the actual script, because I set it up in a way (and I am still not sure that this is the optimal way to do it) that everytime a parameter gets changed, a dump request is committed in order to update the display values on my MIDI controller. But now that I think of it, that is another story, because the timeout message occurs also when just starting up the project (without any knob tweaking) Interesting suggestion, but I am pretty sure the actual data does not collide with any of the MIOS terminal functionalities. Come to think of it, the terminal messages are always introduced by a different SysEx Header .. static const u8 sysex_header[5] = { 0xf0, 0x00, 0x00, 0x7e, 0x50 }; ..taken out of the mbng_sysex.c file. This is why I do not think there is a collision, I hope I did not misunderstand anything there. The message for the 52nd value includes an ordinary byte value encapsuled in the same SysEx stream as the other values form the dump are, hence my assumption. Thanks again for sharing your thoughts with me on this issue, I appreciate it!

Hello Zam, thanks again for your reply :) Upon your response I had to do some thinking and looking up.. I mainly tried to figure out a way to check the optocoupler on the jacks of my I/O Board, but I honestly just did not get it. Also been looking for a way to adjust the baudrate (I thought this would probably be implemented in the app.c itself?), also no luck. The thing I COULD try immediately of course was switching the original cable (5m) for a significantly shorter one (1,5m I guess). I dearly hoped that this could have been the solution, but that was not the case. Still the timeout errors occur on the same commands, just like before. I guess I have just to have to take it then. A while ago I could make some improvements by injecting some delay_ms commands in the ngr script. Though this is not a desirable solution obviously...

I was wondering about how the pre-definition of the SysEx STREAM_MAX_SIZE variable (as 128) in mnbg_event.c came about. The reason I am asking is that I have recurring problem with [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 which, as I have found in other posts, means that there is an overflow on MIDI In 2. In my setup this is the "return" port of a hardware synthesizer, that I am controlling with control elements on another MIDI hardware device (bidirectionally connected on MIDI In/Out 1). While switching through various editing modi on device 2 it always sends a SysEx dump of the parameter values currently set in the selected program/patch. I am reading these values with syxdump_pos=x:y, syxdump_pos=x:y+1, ...., syxdump_pos=x:y+n and assigning them each to a control element on device 1. This setup shows me that the SysEx dumps is (always) cut off at syxdump_pos:x:52. This confuses me, as I can not explain why an overflow, and a subsequent disposal of further incoming bytes, happens so early, since the MAX_SIZE is set to 128... Of course there are probably some additional messages being transferred (like Ack messages for the successfully received dump request etc.), but still this does not make much sense to me. I tried to cope with this by increasing the STREAM_MAX_SIZE in mbng_event.c to 256. Same result , though. I can't come up with any other to deal with this I must honestly say. Has anyone else experienced similar problems when handling the transfer of SysEx parameter dumps? I'd love to hear your thoughts about this. Greetings, Micha

Hey Zam, thanks for the reply! This is actually what I was wondering about.. I was hoping for a way to let the hardware scan the SD card for .NGC files. I thought that maybe by sticking to a pre-defined structuring, for example putting the ngc/ngl/ngr files (belonging to one target platform) into one folder, which would also be a standard procedure I guess, I could make one of the sd card functions in app.c or in mbng_file.c (I really did not quite get how the SD card handling works to be honest..) look for these paths and then print out the names of these folders on my display. If the approach I was going for is impossible to implement, then i will defintely will go for this solution! Greetings, Micha

I was wondering about if/how it is possible to access different .ngc files on an SD card without using the MIOS Studio "detour". My setup consists of the STM32F4 and two external, bidirectionally connected, MIDI hardware elements, one of which is supposed to be used to control the other. The configuration of this setup is obviously defined by NGC/NGR/NGL files. I use a bunch of different ones (can be called from an omni-accessible "main"-screen) for the same setup, but if I want to choose an entirely different configuration setup I would do so by entering "load xy" in the MIOS Studio terminal. I would like to avoid that and set up a kind of "configuration" menu from which I can somehow choose between different .ngc files which I can load to the core the same way I would do by typing in "load xy" in the MIOS terminal. The goal here is to load different control files to control various hardware devices. If anyone has ever done anything like that I would love to hear how you guys accomplished that!

I found some posts here with similar thematics, but it did never seem quite covered for my application case, so I thought I'd start a new one.. I am reading and processing a program parameter dump from a hardware synthesizer, and some of its parameters are woven into one single byte of the dump (for example the activation and polarity of certain envelope parameters can be (de-)activated/polarity-switched). And since I want to control these parameters from a hardware controller, I need to read and display the, currently set, values on the controller's displays. That is why I am calling syxdump_pos=x:y a lot... It would therefore be perfect to have something like syxdump_pos=x:y:z to call for subdivisions/single-bits. I guess the way to achieve this would be altering the MBNG_EVENT_NotifySyxDump function in in the mbng_event.c file, but I'm not sure how to approach this... Has anyone else ever done anything similar? Or maybe found another way around it?

Hello Zam, In BUTTON:1's case I honestly just set it up like that, because from how I understand it has to have "some" type, although it's supposed to be used merely as boolean. For the SENDERs 10&11 it was also chosen rather arbitrarily, in order have something pop up in the MIOS MIDI In monitor, to see which one (or rather which underlying RECEIVER, which receives Note On/Off messages from the hardware controller) is enabled/disabled. I went on a little with my thinking and tried an approach that omits the toggle idea (although I still firmly believe that this is possible somehow!) and wrote down another idea which is actually closer to what will be required in the actual project: NGC RESET_HW #home button (Control Button on C4) EVENT_RECEIVER id= 4000 type=NoteOn chn=1 key= 15 fwd_id=SENDER:4000 EVENT_SENDER id= 4000 if_equal_stop_on_match=RECEIVER:4000:127 type=Meta meta=RunSection:0 #pgrm mode select with simultaneous dump request for currently selected program EVENT_RECEIVER id= 3000 bank= 0 fwd_id=SENDER:3000 type=NoteOn chn=1 key= 32 range= 0:127 EVENT_SENDER id= 3000 type=SysEx stream="0xf0 0x42 0x30 0x24 0x4e 0x04 0x10 0xf7 0xf0 0x42 0x30 0x24 0x10 0xf7" ports=0100010000000000 label="PrgrmMode enter" EVENT_SENDER id= 3001 hw_id= 3000 if_equal_stop_on_match=RECEIVER:3000:127 type=Meta meta=RunSection:1 #single (currentprogram) dump requester for continuous retriggeration EVENT_SENDER id= 4001 bank=1 type=SysEx stream="0xf0 0x42 0x30 0x24 0x10 0xf7" ports=0100010000000000 label="Current Prgrm Dump Request" #current program dump receiver EVENT_RECEIVER id= 4001 bank=1 type=SysEx stream="0xf0 0x42 0x30 0x24 0x40 ^dump 0xf7" ports=0100010000000000 label="Current Program Dump received" #prints the "Delay" string on 2nd display 6th slot upper line #has to be triggered by ngr script EVENT_SENDER id= 1 bank=1 type=SysEx stream="0xf0 0x00 0x00 0x66 0x17 0x31 0x23 ^label 0xf7" ports=1000100000001000 label="Delay" #prints Delay value on 2nd display 6th slot lower line EVENT_SENDER id=101 bank=1 type=SysEx stream="0xf0 0x00 0x00 0x66 0x17 0x31 0x5b ^macdis 0xf7" syxdump_pos=4001:14 ports=1000100000001000 #knob turn on Mackie C4 causing relative and speed dependant value (>64 & <64) EVENT_RECEIVER id= 1 bank=1 type=CC chn=1 cc=13 range= 0:127 ports=1000100000001000 label="Delay value changer" #dummy endoder which gets modified by NGR script depending on what comes from CC 13 EVENT_ENC id= 1 bank=1 fwd_id=SENDER:201 type=CC range=0:89 syxdump_pos=4001:14 #Sender to refresh the modified value with a 41paramChange function sysex stream EVENT_SENDER id= 201 fwd_id=SENDER:4001 bank=1 if_equal=RECEIVER:101:127 type=SysEx stream="0xf0 0x42 0x30 0x24 0x41 0x05 ^val 0x00 0xf7" ports=0100010000000000 #the push of this button finally enables the sending of the sysex stream that changes the parameter's #value EVENT_RECEIVER id= 101 bank=1 type=NoteOn chn=1 key= 45 range= 0:127 NGR if ^section == 0 set ^bank 0 log section 0 running endif if ^section == 1 set ^bank 1 log section 1 running trigger SENDER:1 if RECEIVER:1 > 0 if RECEIVER:1 < 63 log "less than 63" set ENC:1 [ENC:1 + 1] else log "more than 63" set ENC:1 [ENC:1 - 1] endif endif endif Unfortunately, this does not work either. After section 1 has been entered (and thus, bank was switched to "1" etc.) it should be possible to move the Encoder identified by RECEIVER:1 to change ENC:1's value with the aid of the NGR script. This ENC's value is set to a certain range which matches the range of the synthesizer's parameter that I try to remotely modify here with the Mackie. THE MAIN PROBLEM with all of that, is that the Mackie sends relative, not absolute, values (that's what I tried to cope with the NGR script, and that's why the ENC:1 works as a dummy, that initially gets the current parameter value from the sysex dump). So the Mackie is actually supposed to in-/decrement the dummy Encoder and then after that, SENDER:201 sends out a "Parameter Change"-SysEx stream to the synthesizer with the updated value.This also gets forwarded to SENDER:4001, which then re-requests the dump, that then gets saved into RECEIVER:4001's dump, which will be used for the display values... and so on. In the beginning of this workaround I did not have last RECEIVER:101, so that led to a terrible loop where the dumpRequest->usingDumpRequestValues->passingItOnToTheParamChangeFunc->dumpRequest was just being retriggered at every cycle of the application, not allowing anything else to happen. That was a logical outcome, unfortunately. Still the introduction of RECEIVER:101 (which equals a push on one of the MAckie's encoders, which would have been something like a "confirm parameter change" button, if t had worked). Interestingly enough, the changing of the ENC by the MAckie's relative value messages works TO SOME EXTENT. This is what I get out of it in the MIDI In monitor: The CC value (which for whatever reason is CC#48, I did not set ENC:1 to that...) "swings" between 21 and 23 although its range is set to 0:89. Sometimes it takes thevalue of 1, which can not be seen in this picture. Hopefully the usecase is a bit clearer now and maybe someone has encountered a similar problem and has a nifty idea on how this can be either solved or avoided.

This seems almost too basic inquire about, but I just can't get my head around how the switching of a dummy button's state back to zero can be done after it has been triggered for the first time to switch from zero to one. The code below is my basic approach, which works up to the point that button 1 has been toggled from 0 to 1. Only then does the 2nd receiver react etc. I think this is clear. But the push of the hardware encoder identified by receiver 1 should obviously also be able to toggle the button back to state 0. How do you guys do this? #receiver to accept mackie knob push EVENT_RECEIVER id= 1 fwd_id=SENDER:1 type=NoteOn chn=1 key= 45 range= 0:127 #letting through only 127 to prevent a double triggering by the note off (vel 0) event EVENT_SENDER id= 1 hw_id= 1 type=Meta if_equal=RECEIVER:1:127 meta=SendEvent:BUTTON:1:0:1 EVENT_BUTTON id= 1 type=CC button_mode=Toggle range= 0:1 #this receiver will only work after button 1 has been triggered EVENT_RECEIVER id= 2 fwd_id=SENDER:2 type=NoteOn chn=1 if_equal=BUTTON:1:1 key= 44 range= 127:127 EVENT_SENDER id= 2 type=CC range=0:127 It can not be that complicated I'm probably missing something syntax-wise. And I know this could also be handled by an NGR script, but I have a feeling that I am thinking too complicated. Could anyone maybe show an example of how he/she used a dummy button to enable/disable a functionality in his/her project? Any excerpts would be highly appreciated! EDIT: Ok, so I think this example is a bit more tidied up.. #receiver to accept mackie knob push EVENT_RECEIVER id= 1 bank= 0 fwd_id=SENDER:1 type=NoteOn chn=1 key= 45 range= 0:1 EVENT_SENDER id= 1 hw_id= 1 bank= 0 fwd_id=BUTTON:1 if_equal=RECEIVER:1:1 #dummy button EVENT_BUTTON id= 1 bank= 0 type=CC button_mode=Toggle range= 0:1 #if the dummy is not highlighted (value=0) select it and set its value to 1 EVENT_SENDER id= 4 hw_id= 2 type=Meta meta=SendEvent:BUTTON:1:1:1 #if the dummy is highlighted (value=1) select it and set its value to 0 EVENT_SENDER id= 5 hw_id= 2 type=Meta meta=SendEvent:BUTTON:1:0:0 EVENT_RECEIVER id= 10 fwd_id=SENDER:10 type=NoteOn chn=1 if_equal=BUTTON:1:1 key= 44 range= 0:127 EVENT_SENDER id= 10 type=CC range=0:127 EVENT_RECEIVER id= 11 fwd_id=SENDER:11 type=NoteOn chn=1 if_equal=BUTTON:1:0 key= 46 range= 0:127 EVENT_SENDER id= 11 type=CC range=0:127 On program startup the Button's value is 0, so key 46 can be triggered (44 is disabled) and after triggering key 45 the button's value is set to 1, as intended.Thus, key 46 is disabled and key 44 now triggerable. But another push on key 45 does not revert the effect! The problem has to lie somewhere in the SENDERs 4&5, but I still do not get how else it should be done.