Jump to content

m.str

Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    1

m.str last won the day on June 12 2020

m.str had the most liked content!

Community Reputation

1 Neutral

About m.str

  • Rank
    MIDIbox Newbie

Profile Information

  • Gender
    Male
  • Location
    Cologne, Germany

Recent Profile Visitors

198 profile views
  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 trac
  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 th
  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 ki
  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 positio
  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 time
  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 dum
  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.
  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.
  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 calli
  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 so
  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 pus
×
×
  • Create New...