Jump to content

m.str

Members
  • Posts

    29
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by m.str

  1. 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.
  2. 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
  3. And yes you are right, that was totally unnecessary. I probably copied that by mistake from the line above
  4. 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.
  5. 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
  6. 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
  7. Hey, have you tried using different banks? And then activating/deactivating parameter modification depending on bank settings?
  8. 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!
  9. 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...
  10. 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
  11. 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
  12. 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!
  13. 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?
  14. 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.
  15. 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.
  16. Hey Peter, thanks for the reply. At this point, it seems solved! Interestingly enough the error still came up when I ttried the first approach I inserted the free() call after this for loop, so after the array values had been processed and were no further used. This is what made the most sense to me. That the error still occured worries me a bit, because that MIGHT mean, that it's something else... On the other hand I tried your second approach by turning this to this //initialize array and pointer for the 6-field Display values u8 macdis_array[6]; and this is working at the moment. I hope it stays functional :) Best wishes, Micha
  17. I keep on receiving this error (topic title) in MIOS32 after switching between sections via my ngr script which proceeds to request store SysEx dumps from a connected synth. I have a firm belief about what probably causes the error (the error I could not resolve by research, though.. the term malloc just leads me to think, that there is some memory that is not being freed properly after use) What I did in my c files was introducing a new kind of variable (called ^macdis) for use in SysEx stream sending. What it does is that it resolves a value from a sysEx dump (identified by syxdump_pos:x:y) into a 6-field u8 array to be further used for sending it to a Mackie C4, which uses it to display the value on six fields of one of its displays. I herefore instanciate a u8[6] array here: s32 MBNG_EVENT_SendSysExStream(mios32_midi_port_t port, mbng_event_item_t *item) { u8 *stream_in = item->stream; u32 stream_size = item->stream_size; s16 item_value = item->value; //initialize array and pointer for the 6-field Display values u8 *macdis_array; macdis_array = (u8 *)malloc(sizeof(u8)*6); ..... And I have a feeling that I just did not fully get my head around the whole pointer thing. After repeatedly calling my ngr section 1, which requests and receives the dump and subsequently uses the ^macdis flag to print one value on the mackie (and herefore using the array, which I want to be ONE array, that is cleared after the processing of one incoming value and then used for the next) the error comes up and the whole thing crashes of course. Here is how the (relevant part of) code in mbng_event.c goes on: case MBNG_EVENT_SYSEX_VAR_MACDIS: { int i, j, rest; u8 num = item_value; for(i=5;i>=0;i--){ if(i == 0 || i == 4 || i == 5){ macdis_array = 0x2d; } else{ if(num > 0){ rest = num%10; num /= 10; switch(rest){ case 0: macdis_array = 0x30; break; case 1: macdis_array = 0x31; break; case 2: macdis_array = 0x32; break; case 3: macdis_array = 0x33; break; case 4: macdis_array = 0x34; break; case 5: macdis_array = 0x35; break; case 6: macdis_array = 0x36; break; case 7: macdis_array = 0x37; break; case 8: macdis_array = 0x38; break; case 9: macdis_array = 0x39; break; default: macdis_array = 0x2d; break; } } else{ macdis_array = 0x30; } } } for(j=0;j<6;j++){ MBNG_EVENT_ADD_STREAM(macdis_array[j] & 0x7f); } } break; Since I cannot resolve the error by reasearch I would be grateful for anyone, who might take a quick glance at my code. Maybe someone, who is a bit more experienced in C than I am might see the (possibly obvious) error
  18. So at one point during my development of an app on NG basis on a STM32F4 core, my SesEx tool stopped working. I used it to send messages to both a Mackie C4 and a Korg M3R, which both responded in the beginning. The confusing thing is, that I can still communicate with both via my .ngc and .ngl scripts. I address them both by their ports (Macke on MIDI port 1 = 1000100000001000; M3R on MIDI port 2 = 0100010000000000) and there it works! Still something must have been misconfigured on the way and I can't imagine what, because I'm still pretty much in the beginning. I also used to get SysEx dumps form the M3R on request, which also stopped working..
  19. Hey, thanks for the thread link! I've actually gotten a step further at this point. It IS actually possible to just overwrite the start-up screen by sending the respective SysEx commands. The main reason for my difficulties was that the connection built by the NG project template just didn't suffice to get through... I tried it out with the MIDI 4x4 project.hex file and it worked. I set up my EVENT_SENDERs/RECEIVERs according to the fwd.ngc file and I am in the (still very early) working phase of being able to send "some SysEx" and print "some ASCII sequence" on the Mackie C4 after turning an encoder/pushing an encoder etc. What I was wondering about next was if there is a possibility to store the callback value that the C4 receives, after successfully sending a "value increment" command (triggered by turning the rotary knobs on the C4). My case specifically consists of an NG as interface between the C4 and a Korg M3R Racksynth. The M3R answers the request by returning a SysEx message similar to the one that he was being fed. This message usually also contains the updated value. I've seen in the tutorials that there are SYSEX_VARs. Are those the ones to use here? Also it is of course the plan to, when displaying M3R's program information (which one is selected) on the Mackie, actually put the name there that is used in the Korg manual and displayed on the synth itself. This String is, of course, never part of any communication between the machines, so the idea should be to create a file on the SD card, where program numbers are mapped to the program names, stored as SysEx streams for further use. Does that seem plausible? And is that possible?
  20. I am trying to build a mapping device on NG basis to connect a Mackie C4 Pro to basically every imaginable kind of hardware to make it universally usable. My starting point was reading the MIDI messages coming from the C4, which worked fine. The other way round, though, is giving me a hard time, because the C4 just stays in its startup screen and doesn't react to messages which would work when going through the Mackie Commander software (I already successfully tried that, I can get the displays going and everything) So it seems that when going the way over my MIDIbox something is missing. Like an Ack message to let the C4 know, that it's supposed to listen now. Has anyone ever had a problem similar to this with any kind of hardware controller? I also tried to mirror the power on message sent out by the Mackie and sending it back to it. Didn't work.
  21. Having a similar problem here.. I am running an STM32 core with an additional 2x2 module. The core was pre-programmed, Bootloader installed. When I first connected it there was already a MIDI 4x4 project.hex file on there, which worked because (MIDI IN/OUT in MIOS Studio were MIDI 4x4) I received MIDI messages on the left terminal after moving knobs on the hardware, that was connected to one of the 2x2-module's MIDI In ports. So now I uploaded the NG template project, because this is what I would want to be working with, then the uplaod stops halfway and I get the error message seen above. Upon restarting I can now choose MIDIbox NG in the In/Out section in MIOS Studio, but still the same error. Pushing the black knob on the core module didn't do anything either, except for the sound on Windows that says that spomething has been removed and then re-attached. I couldn't find anything in any guide about the "Device ID" that the error is inquiring about, what's up with that? EDIT: Ok so I just saw now in the bootsloader newbie guide that the Device ID should only matter in the case of multiple MIDIboxes running in parallel. I restarted MIOS Studio and the setting seems like it's okay. MIDI IN/OUT is MIDIbox NG as desired. Additional info might be that the STM32 is connected to a Windows 10 Laptop via a Micro USB cable. The problem is that now I don't get the MIDI messages from the connected hardware, that I got earlier. The connected hardware is a Mavkie C4 Control, which sent a message on startup and of course for every knob/encoder that was triggered
  22. So I am planning to build a microcontroller as an interface between a Mackie C4 Pro and, theoretically, any kind of Hardware/Software component. The component that is to be controlled will be determined, and the configurations specified, by templates which will be stored on an SD card. To realize this I will be using the STM32F4 module with the SD card interface and a MIDI 2x2 module. Eventually another 2x2 is planned to additionally connect a MIDI keyboard. I am a newbie to the MIDIbox forum so I started researching and decided to take the NG project as a starting point. To me this means that in order to implement this I need to alter the .ngc .ngl and .ngr files to a) have a communication with the Mackie that will, basically, always stay the same and b) generically prepare the other side of the microcontroller so that the user can specify the mappings to his hardware/software himself. RPN, NRPN and SysEx must be possible. This of course means that the chosen parameters and their state will be required to be displayed on the Mackie's displays, which, after reading the NG and STM32F4 specifications, I think is possible. A final requirement is that the configurations will have to be stored into a textfile (I was thinking XML) so that the user won't need to actually open the .ngc files and do his settings there, but rather that on startup the device considers the textfile as belonging to a certain configuration file, checks if something was altered in the textfile, if so applies it to the configuration data and then sets that up as the current configuration state. What do you guys think? Does that sound possible? Did I choose the right components? And has anyone ever done something similar and encountered problems that maybe I could encounter too?
  23. Hello there, this might be an old thread but maybe this question will still be answered.. I've only just started out working with MIDIbox, so I set up Eclipse as an IDE (primarily because I used it in the past), but also it seemed like best choice to do from what I read on uCapps. The only other alternative depicted there is "Code Blocks". Never heard about that before, so I can't make an assumption if it's good/bad. You seem to know more alternatives for developing, and I thought maybe you could tell some better options than Eclipse. I mean what do you use for example? And is there any resource where one can look up all the possibilities for IDEs?
  24. Didn't know that was a thing actually.. I always just deleted and reimported the projects. Tried that now, still the same result though.. SOLVED: This morning I threw everything that I had set up according to the instruction manual so far away and re-worked the whole thing anew. Noteably I only set the Env variables in Eclipse and unzipped every upcoming .zip-file with 7-zip. Don't really whatever went wrong there, but that's what fixed it. Thank you Antichambre for your kind help!
  25. Downloaded it again, unpacked it with 7-zip. No error message about a damaged zip file turned up. That was a valuable tip of yours, thanks a lot! Moved it to the right destination. Now this error
×
×
  • Create New...