MIDI Kinetics Forum

I've set up a container with knobs and sliders to control dynamics parameters on my DM1000. They send the sysex data nicely, and control the various console parameters smoothly. If I operate the controls on the console, my knobs and whatnot move on screen to reflect the updated values. So now, I'd like to be able to select the channel I want to edit and have the controls update to the current console settings. Seems simple enough. Send a sysex request for the data (the Yamaha protocol doesn't have a request all sub-parameters for compression that's documented, so I've set up a loop to run 7 times stepping through an array of the parameter values.)
The above code is called from the channel select switches, immediately after sys_channel is set based on firstof(x) being the selected channel. The remainder are globally defined variables specific to the console to generate a complete sysex string, which works great - except...

Problem: I have to press the channel select several times to get all the variables to populate. I suspect that either the data is being sent to the console faster than it can handle, or the responses are coming in faster than Lemur can handle, though I don't know how to sort out which, and frankly don't care. I've searched high and low for something the equivalent of "wait 20;", "sleep 20;", or something simple that would let me just make the dang loop pause for 20 milliseconds or something before running the next iteration to give the whole thing time to send and receive the data.

Attempted solution 1: I looked at several templates in the user library, and tried variations on the "if (time - prevtime < 20)..." syntax, but can't find one that works for a basic loop. Continue on non-match increments the count, which skips a variable. Return skips all but the first iteration. I don't think I want an onFrame script, since I only want it to send the data when I select a new channel. I've been using a Manual script, since that makes the most sense to me. Do this function only when called by the channel select strip.

Attempted solution 2: I added an additional "for(t=0; t<500; t++) {}" before the end of the first loop, and tried a variety of values for the t<500 section. At t<500, it works most of the time, but not always. I still have to press the button 3 times to make absolutely certain.

Attempted solution 3: I tried to integrate the sending and processing into one script so that it would send the threshold request, set the value; send the attack request, set the value; etc... this turned into a horrible mess of code that I gave up on, but if that's the best way to go, I'll revisit it.

Any guidance graciously appreciated. I haven't done any coding since that introductory course in high school, and the rust is taking quite awhile to shake off. The absence of such seemingly simple commands as wait or sleep only adds to the consternation despite my excitement at the opportunities Lemur seems to offer!

Thanks in advance,

CS

been there, done that.......

go look at my do loop post. basically you can't depend on "time" to work inside of a script the way you think it would. Let me see if I can get this right.

Scripts execute in a frame. Frames execute 60 times a second. During a frame, execution time in essence stops. So if you have a loop that compares a value to the internal time constant it's never going to see the internal time constant change during it's execution inside the frame. I'd suggest re-reading the last 3 sentences a couple of times. To try to delay midi sends you have to count frames and use that to get your delays. Each frame is (correct me developers if I'm wrong) 16.6ms.
So to get a delay you need to put your code inside an OnFrame script and use a frame counter to decide if enough real time has elapsed. Believe me, I beat my head against this for a while until I got a handle on the "frame time" factor. My issue was that I was sending midi to a device that needed 60-90ms between midi events to work properly. I am using 6 frames (although I have a fader to tweak the number of frames) and it works like a charm. I am including a little project that might give you an idea on how to implement the frame factor.

HTH,

joeb

Thanks! I think that just might do what I need. I hadn't thought of that approach to delay. Very circuitous method, but I think it just might work. Apparently I'm not the only having this problem, since three people downloaded your solution before I even got home from work. Haha. It'd be great if the developers could include a delay / wait / sleep command of some sort - hint, hint, hint...

Doubt that's gonna happen. I think it would involve a major rewrite which might not make the software version compatible with the old hardware Lemur. But what the hey do I know. My template is working just like I want it to but now I'm bumping up against saving and loading midi files from the Mac side which majorly defeats the whole purpose of my app running on the iPad. And since a lot of what I do is using the iPad far from a desk/laptop I have to keep Lemur running and when I get back to the Mac I've been sending my midi sequences back thru midi monitor, copying the list from midi monitor, pasting it into BBEdit, modifying it to fit the Lemur XML structure and then pasting it into my one of my sequencer slots in my template. Talk about HINT, HINT, HINT....... saving and reading midi files onto the iPad itself is right at the top of my wish list. Followed closely by bigger and multi-dimensional arrays. I can live with having to write a keyboard interface to name things because there is no editable text object but those 3 items are a serious limitation to what I'm trying to do. So if it works doesn't matter how ugly it is until we get some of the things on our wish lists.

Good luck and let me know how it goes with the timing.

joeb

Work got in the way of working on this much today. I'm definitely going to make use of your framecounter when I implement meters to keep data transfer to a minimum. First thing I tried today was plugging in standard MIDI cables through my sound card instead of using the Yamaha USB MIDI driver. It was able to pull up to 16+8+7+21 parameters (most I use in my scripts) simultaneously without any glitches, every single time. I got distracted getting the HA function working for the LS9 since we have concerts again next week, and I'd love to have that functionality working - can't stand how the StageMix app doesn't have compression control, which is what got me started on this project to start with. Then I got tired of switching between apps, so just building my own complete mixer control surface that's laid out how I want to use it. Really pleased with the progress, despite some frustrating hiccups along the way.

Joe - thanks for the hints. Knowing that time "stops" while you're processing a frame provided the big piece of the puzzle that I was missing. The framecounter works perfectly. Here's how I decided to go about doing what I needed. Don't have the specific code in front of me, so the middle bit is just a comment line. My variable "framecounter" is set at the project level to equal 0. This was the simplest way I could come up with to have a timer of sorts that executes a code every now and then, and resets itself after each execution.
Arriving at 200 took a little experimentation. When you send a meter request, the console kicks out response data for a few seconds. I never did bother actually timing anything. Basically, I wanted to minimize the amount of data being sent without losing functionality. I set it to send a request every 400 frames initially. Watched the blinking MIDI in LED. Adjusted the number until the stream of meter data never stops. At 208, it drops out momentarily. 200 seems safe. I'll have to keep an eye on it as I add more to the template to see if I have to drop just a little more to keep within the timeout range.

The manual should describe frames the way you did in your response.

CS

Glad you got it working! Can't take credit for the explanation. That came from macciza and axel_line. I just reworded it to how I understood it. No biggie. The goal was to get it working and it looks like it is. Just glad to give back. Was asking a ton of questions when I first started. I actually got around another problem of the VST not responding to midi in an Abelton Live composition. Got that working so I feel like a pig in very deep do-do!! Used a second send/receive as a monitor and it works. So in the middle of an audio track I can add and remove things from my template right into the VST stream. Very sweet.

Congrats on your solution and please ask. I might actually have an answer!

best regards,

joeb

Thanks Joe

Glad to see you passing on the info in this and some other threads
We are getting a quite nice community happening . . .
Regards
MM

No worries. Making the transition from on the last nerve IT contractor to retired person has been a challenge in more ways that I would have thought. Getting past "OMG its got to get finished NOW!" to "Take your time, don't need to rush" has been a tough 45 year habit to break. But the cracks are forming and every little bit of help that I give out seems to crack a little bit more. Of course I am now fighting the last 5% of a project, getting the bugs out, and it's amazing how good it feels to say its starting to frustrate me so I need to walk away and actually realize that now I can.
Like I said, payback for all the effort you and others have made with me. Glad that I am fitting into the community and CAN be of help. I promise that I'll release this growing monster soon. It is quite nifty and now that I got around the VST thing I'm adding minimal DAW control for Live.

Thanks for all the good vibes here!

Joe B