• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About m.str

  • Rank
    MIDIbox Newbie

Profile Information

  • Gender Male
  • Location Cologne, Germany

Recent Profile Visitors

78 profile views
  1. proper use of button type=toggle as dummy

    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.
  2. 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.
  3. 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 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
  4. 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
  5. 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..
  6. 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?
  7. 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.
  8. No device id on MIOS Studio

    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
  9. 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?
  10. 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?
  11. 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!
  12. 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  
  13. It is found by the explorer's search function. and I find it by moving to it manually. Everytime I moved the folder around I also re-set the environment variables, both in Windows and in Eclipse. I now removed the one in the Windows settings, to no success... After relocating the toolchain folder to just C:/toolchain this is the value of my PATH Variable in Eclipse              C:\msys\1.0\bin;C:\toolchain\bin (Append variables to native environment selected)
  14. Okay so I found that the MIOS32_PATH was wrong, I actually thought that just because the "/c/" part is lower case everything had to be lower case... Anyway there is another error, now with the toolchain EDIT: While tyring to move aroung the gcc folder and then unzip it again from the file that was introduced in the tutorial I noticed that the .zip file is damaged (Warning during the unzip processing). The Process of unzipping still finishes and the file that is mentioned in the Eclipse eroor IS there, but maybe that's still the source of error. Does anyone know another place where I can get a non-corrupted zip-file?  
  15. Thank you for the warm welcome! Beziehungsweise "danke", denn ich komme auch aus Deutschland was hier wie ich sehe nicht angezeigt wird :) Anyways, it's still better to continue in English, because unfortunately I have another/similar problem... The PATH Variable seems to be incorrect, but i cannot really imagine why.. Hence I added the pictures, what am I missing?