Probing for MIDI devices - need help

[oldgearguy]

I am struggling conceptually with the best way (or any way ) to implement some functionality, so I thought I'd post and see if anyone has an idea.

At a high level, what I want to do is to have a script on Lemur probe the 16 MIDI channels on a target and if a device is found, log the returned info.

More detail -- I have an old synth (Yamaha TX-816) that is effectively 8 synthesizers in a rack. Each slot can be configured for a different MIDI channel as well as other settings. I have a defined 'get status' message of 5 bytes and a 'current status returned' response of 16 bytes, so the traffic is fairly minimal. I wanted to automatically probe to see if the slot has a synth and get the info from it.

In other procedural languages, I'd simply code up a loop for i=0 to 15, do a midiout(), wait for a response with a timer or delay, and then either log the returned data or move on if I time out. In the land of Lemur, the 'wait for a response and then move on' part is not a standard construct. How can I do something like that? Do the new MIDI clocks in 5.0 help?

Yes, I know I could ask the user to manually set up all that info, but it would be nice to do it automatically. This particular task is not the first time (and probably not the last time) I'll need to wait on something (a response from the user, a response from a connected device, etc).

Thanks in advance for any ideas/snippets/thoughts on this issue.

[Macciza]

Hi
Its not just Lemur that does not really do the 'wait for response' paradigm, its a general OO thing as well I guess . . .
Wait states or timers can be achieved using time() manipulations or frame counts as a basis

I think you just need to approach it differently
Send a message and set a timed flag, have a midi in script that executes only when the flag and appropriate message coincide . .
Have a timer and script that steps through the various calls and oversees the whole thing
Using Containers as 'objects' can help, you can hold data and functions in them and address it all fairly easily . . .

As the data is fairly small you possibly may not even need very large waits - more just for the device response time . . .

No code of the top of my head but may come back to it . .
MM

[oldgearguy]

Understood that it's more an OO thing than a Lemur thing, but Lemur also has this frame concept which adds some extra thought processing to get right.

So let me make sure my understanding of how Lemur works is accurate and then after that we can work through the problem since I think some of my false starts have been due to an incomplete understanding of how it all functions --

Lemur has a concept of a frame, which in old computer terms could be like a timeslice. So, at the start of each frame any 'on-frame' scripts are processed. When the scripts are processed, all external variables referenced in the script are instantiated to their current values and the script is run. This means that external variables are not re-evaluated during the life of that script in that frame. IOW - if an on-frame script was watching a button, the value used inside that script would be whatever the button state was when the script started processing and even if the state changed during the time the script was running, the change would not be seen in that script in that frame.
Scripts that trigger 'on expression' run when the condition is met, but they also have a limited time to run. Is that time an entire frame or is it: frame_window - current time in that window?

At the end of the frame, a script has either run to completion or else it is forcefully halted when the frame ends.
Scripts can call other scripts and they will wait at that point for the called script to complete. If the frame ends before the called script returns, any expected return value is indeterminate.

Is recursion allowed? (a script calls itself - I don't think so, but maybe I didn't understand the variable instantiation thing at the time I tested recursion)

Are variable values saved across invocations? What I mean is -- if I declare a local variable in a script and don't initialize it and then it gets set as a result of a slider movement or something, the next time that script is called, does the variable still retain the old value or does Lemur invisibly initialize local variables each time a script is called?

Are global variables saved across template startups? If I set a configuration up in a template and then exit, the next time I start that template are my internal configuration settings saved and reused?

One last one -- if I set a bunch of values in a script that is triggered 'onload', and other scripts are set to trigger 'on expression' based on those values, do all those scripts get triggered during that same frame or is the 'on expression' conditions only evaluated at the start of every frame? So, onload() is setting the x value of a fader to 0.5. In that fader definition, I have an 'on expression, x, any' script. Is that script triggered as soon as x is changed, or does Lemur wait until the next frame to evaluate x and trigger the script?

I can certainly test some of these things later in the day, but I don't have 24/7 acces to a Lemur environment, so if someone has definite answers now, that would help and I can always update this post with info later.

Thanks for any clarifications or corrections you can provide.

[electrofux]

I probably haven't understood what you want to do but couldnt you just set up 16 On Midi scripts (well, or 1 with all channels) and see what comes in if something comes in?

When you probe your Synths Channels and there is a success it will send a Sysex back, right? I dont understand why you need a timer or delay for that.

[oldgearguy]

I probably haven't understood what you want to do but couldnt you just set up 16 On Midi scripts (well, or 1 with all channels) and see what comes in if something comes in?

When you probe your Synths Channels and there is a success it will send a Sysex back, right? I dont understand why you need a timer or delay for that.

Part of the reason for posting is to see if anyone has another way to solve the problem. I'm certainly open to any/all ideas.


The problem is - what if it doesn't send anything back? I understand that in this particular case the send/receive loop will be fairly quick, but if I try to automate this process on startup, I can't say "wait and don't start editing until all the probing is complete" because there's no notion of waiting. In addition, since I am probing all 16 MIDI channels on a single synth, I can't fire off 16 consecutive queries without some type of delay between them because it will likely overwhelm the device and cause data errors and loss of transmission (late 1980's technology here).

The TX-816 is effectively 8 DX7's in a rack. Each module can have its own MIDI channel (user-configurable). A further limitation is that even though you can talk to all 8 modules at once, you need to select a module for output via a front panel pushbutton, so with a stock system, a user has to manually cycle through each module. A future implementation will allow me to add in a small daughterboard to allow MIDI control over that manual pushbutton, but I'll still need an iterative process like: go to module 1, cycle through all 16 channels until I find a hit, go to module 2, cycle, etc. Note that not all slots have modules and there can be gaps, so I could be parked on an empty slot, cycle through all 16 MIDI channels, and still not find anything.

Of course, the easy/initial answer is for the user to manually configure the Lemur template, but this is not the first time I have wanted a delay/wait/user interaction method.

[electrofux]

right off my head : an on clock script with a counter would be an easy triggerable delay.

Send the probe and start the onclock , wait until the onclock script has counted to x and look into the Midi in script.

[oldgearguy]

here's a quick clock test script to do a delay. I think this is the right path for what I want. I still have lots of other questions, but for now I think this will work.

clocky.jzml

quick delay test using MIDI clocks

(3.49 KiB) Downloaded 89 times