Troubleshooting
Linking or double messaging from a fader
Started by sleeper on .
Sign in or create an account to join the conversation.
I'm just not understanding something.
I've looked and lifted from the linked objects tutorials. Read the manual. Over and over the appropriate sections...
Learned alot, but im not quite understanding how to write the values and triggers correctly- I guess.
it's sure not working I've tried a bunch of things and I'm stumped on this. please help.
In the container.
I've got 2 faders that control some channels in my RME totalmix.
I want them to move as a stereo pair
with only x and z checked Level and Level2 are working individually perfect with totalmix. so thats good
if I check/activate the expression named Level2.act() it makes both faders move when I move Level2 in lemur, but no movement on the software. ?,
my x value seems to be getting stopped somewhere. ?
the better solution for my interface is is one fader 2 midi cc messages. it seems easy.
I've added a custom midi message Level.l
but once again, I'm doing something wrong with the values and triggers. i've tried a bunch of combinations, it doesn't work. I need a key.
I'll bet when I have a better understanding of the value /trigger thing I'll be able to get that monitor working.
arggh.
Thanks for any help
Sleeper-linked fadersR1.jzlib
I've looked and lifted from the linked objects tutorials. Read the manual. Over and over the appropriate sections...
Learned alot, but im not quite understanding how to write the values and triggers correctly- I guess.
it's sure not working I've tried a bunch of things and I'm stumped on this. please help.
In the container.
I've got 2 faders that control some channels in my RME totalmix.
I want them to move as a stereo pair
with only x and z checked Level and Level2 are working individually perfect with totalmix. so thats good
if I check/activate the expression named Level2.act() it makes both faders move when I move Level2 in lemur, but no movement on the software. ?,
my x value seems to be getting stopped somewhere. ?
the better solution for my interface is is one fader 2 midi cc messages. it seems easy.
I've added a custom midi message Level.l
but once again, I'm doing something wrong with the values and triggers. i've tried a bunch of combinations, it doesn't work. I need a key.
I'll bet when I have a better understanding of the value /trigger thing I'll be able to get that monitor working.
arggh.
Thanks for any help
Sleeper-linked fadersR1.jzlib
let me rephrase this.
for my fader named Level (BTW this is working and controls RME totalmix channel ADAT out 7
expression x is as follows
Message BO- control change
controller 102
Value x[0] any
Scale 0-127
channel 10 to 10
for my fader named Level2 BTW this is working and controls RME totalmix channel ADAT out 8
expression x is as follows
Message BO- control change
controller 103
Value x[0] any
Scale 0-127
channel 10 to 10
This script makes both faders move in unison, but they doesn't send the cc message on x
on expression x
Level.x=x;
Level2.x=x;
This custom midi message applied to fader "Level" makes "Level2" work but it's jumpy and "Level" stops working.
weird. why is my x disappearing.
It's as close as I've gotten.
custom midi message named "l"
Message BO- control change
controller 103
Value x[0]
Scale 0-127
channel 10 to 10
Trigger level
There's nothing in the manual that gives any detail about this kind of assignment. I've read the hell out of it.
Tried all kinds of different variations.... Am I not using parentheses correctly or something.
Little help please.
Thanks
for my fader named Level (BTW this is working and controls RME totalmix channel ADAT out 7
expression x is as follows
Message BO- control change
controller 102
Value x[0] any
Scale 0-127
channel 10 to 10
for my fader named Level2 BTW this is working and controls RME totalmix channel ADAT out 8
expression x is as follows
Message BO- control change
controller 103
Value x[0] any
Scale 0-127
channel 10 to 10
This script makes both faders move in unison, but they doesn't send the cc message on x
on expression x
Level.x=x;
Level2.x=x;
This custom midi message applied to fader "Level" makes "Level2" work but it's jumpy and "Level" stops working.
weird. why is my x disappearing.
It's as close as I've gotten.
custom midi message named "l"
Message BO- control change
controller 103
Value x[0]
Scale 0-127
channel 10 to 10
Trigger level
There's nothing in the manual that gives any detail about this kind of assignment. I've read the hell out of it.
Tried all kinds of different variations.... Am I not using parentheses correctly or something.
Little help please.
Thanks
Hi
Have you seen this stuff https://forum.liine.net/viewtopic.php?f=34&t=3125
Have a look through that and see how you go . .
I'll try and have a look at what you did and comment later
Have you seen this stuff https://forum.liine.net/viewtopic.php?f=34&t=3125
Have a look through that and see how you go . .
I'll try and have a look at what you did and comment later
not sure if this helps or hurts --
I made a couple tweaks to your file. Now, both faders always move together. Also, Level has 2 CC messages associated with it - I simply copied "l" and made "l2" which sends the value of level2 fader.x out.
Again - not sure if either/both of these changes are useful for what you need. I am pressed for time, so I can't set up a MIDI monitor to see what's coming out of this script, but it may be of use.
Untitled.jzml
I made a couple tweaks to your file. Now, both faders always move together. Also, Level has 2 CC messages associated with it - I simply copied "l" and made "l2" which sends the value of level2 fader.x out.
Again - not sure if either/both of these changes are useful for what you need. I am pressed for time, so I can't set up a MIDI monitor to see what's coming out of this script, but it may be of use.
Untitled.jzml
Hi Oldgearguy,
Thanks a ton,
don't worry I'm not in a rush.
I see what you've done and I'm feeling better about the usage of parantheses{} and brackets[]
This monitor script works! {Level.x, Level2.x}*127
I added the multiplier. Cool.
hell, I even guessed right about a few things.
As far as I can see what you did should work. We pretty much did it the same way.
I expected it would work. (I feel better that at least I wasn't being dumb here.)
but it's still not working.
I can see strange behavior on my computers midi monitor.
Let me step through whats happening. using your example
All scripts OFF
OK both faders on RME work. Midi Messages look normal
move Level sent 10 102 01 , 10 102, 02 etc. to 10 102 127
move Level2 sent 10 103 01 , 10 103, 02 etc. to 10 103 127
If I turn on Level and Level2 scripts the faders are linked and both messages are sent
problem seems to be that lemur is sending the cc message between 10 and 24 times for each step.
midi monitor sees this:
10 102 69
10 102 69
10 102 69 etc. etc. etc.
10 103 69
10 103 69 etc and my faders jump around or don't move at all.
the more slowly I move the faders the more times it sends the message...
OK I fixed this by switching physics to NONE in the behavior panel
The problem with the scripts seems to be that they are spitting out info that is timestamped exactly the same...
12:53:44.774 From Daemon Input 1 Control 10 Controller 102 57
12:53:44.774 From Daemon Input 1 Control 10 Controller 103 57
Is there some way to add a small delay to a script?
As far as the custom midi messages -
if I enable L and L2
and
If I disable the 2 act scripts Level/act() and Level2/act()
they aren't transmitting the 103 value at all.
Actually, with only L turned on
the value set as either Level[x] or simply x
and no trigger specified I get out...
13:10:14.923 From Daemon Input 1 Control 10 Controller 102 78
13:10:14.923 From Daemon Input 1 Control 10 Controller 103 78
grr.
so maybe I wan't so far off all along.
But it's not working, and this -I guess- is tied to the messages coming out at the same time?
Is there some way to add a small delay to a custom midi message?
If you know how to do it, fantastic, In the meantime I'll search for that
and yes,
I've also learned that I need to have midi monitor up whenever I start troubleshooting,
because I missed seeing what the real problem was. it's still a problem.
Thanks
Sleeper
Macciza, seriously, I don't want to be a troll-ish newbie, I know you are a yellowshirt of some sort, but seriously, give me some credit here, every question I've posted thus far on the forums, you've told me to look at something I've already torn apart 3 different ways - and said so or provided concrete examples in my posts.
I don't want to alienate you from providing support that I need, but I've spent tons of time on forums like prodigy pro etc. I know the drill.
I have no interest in posting about things I haven't already researched and I'm not here to waste your time.
I've already looked at all the examples in linked faders and I'm pretty sure my situation isn't there. Soooooo... yeah. That.
Thanks a ton,
don't worry I'm not in a rush.
I see what you've done and I'm feeling better about the usage of parantheses{} and brackets[]
This monitor script works! {Level.x, Level2.x}*127
I added the multiplier. Cool.
hell, I even guessed right about a few things.
As far as I can see what you did should work. We pretty much did it the same way.
I expected it would work. (I feel better that at least I wasn't being dumb here.)
but it's still not working.
I can see strange behavior on my computers midi monitor.
Let me step through whats happening. using your example
All scripts OFF
OK both faders on RME work. Midi Messages look normal
move Level sent 10 102 01 , 10 102, 02 etc. to 10 102 127
move Level2 sent 10 103 01 , 10 103, 02 etc. to 10 103 127
If I turn on Level and Level2 scripts the faders are linked and both messages are sent
problem seems to be that lemur is sending the cc message between 10 and 24 times for each step.
midi monitor sees this:
10 102 69
10 102 69
10 102 69 etc. etc. etc.
10 103 69
10 103 69 etc and my faders jump around or don't move at all.
the more slowly I move the faders the more times it sends the message...
OK I fixed this by switching physics to NONE in the behavior panel
The problem with the scripts seems to be that they are spitting out info that is timestamped exactly the same...
12:53:44.774 From Daemon Input 1 Control 10 Controller 102 57
12:53:44.774 From Daemon Input 1 Control 10 Controller 103 57
Is there some way to add a small delay to a script?
As far as the custom midi messages -
if I enable L and L2
and
If I disable the 2 act scripts Level/act() and Level2/act()
they aren't transmitting the 103 value at all.
Actually, with only L turned on
the value set as either Level[x] or simply x
and no trigger specified I get out...
13:10:14.923 From Daemon Input 1 Control 10 Controller 102 78
13:10:14.923 From Daemon Input 1 Control 10 Controller 103 78
grr.
so maybe I wan't so far off all along.
But it's not working, and this -I guess- is tied to the messages coming out at the same time?
Is there some way to add a small delay to a custom midi message?
If you know how to do it, fantastic, In the meantime I'll search for that
and yes,
I've also learned that I need to have midi monitor up whenever I start troubleshooting,
because I missed seeing what the real problem was. it's still a problem.
Thanks
Sleeper
Macciza, seriously, I don't want to be a troll-ish newbie, I know you are a yellowshirt of some sort, but seriously, give me some credit here, every question I've posted thus far on the forums, you've told me to look at something I've already torn apart 3 different ways - and said so or provided concrete examples in my posts.
I don't want to alienate you from providing support that I need, but I've spent tons of time on forums like prodigy pro etc. I know the drill.
I have no interest in posting about things I haven't already researched and I'm not here to waste your time.
I've already looked at all the examples in linked faders and I'm pretty sure my situation isn't there. Soooooo... yeah. That.
Hi OldGearguy again,
I was looking at your "clocky" script.
I'm not sure if it would be better to write it like:
on expression x -
cause midi cc to delay a couple clock bits before sending cc103
or
on MIDI Control Midi Target 10 t0 10 10 to 10 (I guess those are channel numbers in the script editor ? -I'm not changing channels)
delay x by a couple of clock bits.
or delay cc 103 by a couple of clock bits.
Anyhow.I know how to conceptualize it.
zero Idea how to write it. I'll be working on that.
I was looking at your "clocky" script.
for this situation hereif (floor(clock_getbeats(0)) - saved_beats > 2) {
Monitor.value = 'Wait Over';
saved_beats = floor(clock_getbeats(0));
}
else
Monitor.value = 'Still waiting';
I'm not sure if it would be better to write it like:
on expression x -
cause midi cc to delay a couple clock bits before sending cc103
or
on MIDI Control Midi Target 10 t0 10 10 to 10 (I guess those are channel numbers in the script editor ? -I'm not changing channels)
delay x by a couple of clock bits.
or delay cc 103 by a couple of clock bits.
Anyhow.I know how to conceptualize it.
zero Idea how to write it. I'll be working on that.
Can you summarize the behavior you want to see?
I am guessing that you want to move a single fader and have it send MIDI CC's 102 and 103 based on the fader position. Is that basically it?
Do you need 2 separate faders or will just 1 work (if it sends out both messages)?
Here is a script that has a stereo pair of sliders and moving either slider will send out CC 102 and CC 103 values.
Note the small changes -- x and z are disabled, the target for l and l2 is MIDI 0 (since I use port 0). I didn't change the MIDI channel and watching the Monitor and the data going to MIDI-Ox, I see exactly one value change for 102 and 103 for each movement increment of the slider.
Hope this helps
Tom
paired.jzml
I am guessing that you want to move a single fader and have it send MIDI CC's 102 and 103 based on the fader position. Is that basically it?
Do you need 2 separate faders or will just 1 work (if it sends out both messages)?
Here is a script that has a stereo pair of sliders and moving either slider will send out CC 102 and CC 103 values.
Note the small changes -- x and z are disabled, the target for l and l2 is MIDI 0 (since I use port 0). I didn't change the MIDI channel and watching the Monitor and the data going to MIDI-Ox, I see exactly one value change for 102 and 103 for each movement increment of the slider.
Hope this helps
Tom
paired.jzml
one would work just fine.
so YES
So
maybe I should say
and add a slight delay to messages on 103
so YES
which is what the the custom midi messages are doing. but this is choking the RME software I assume because the messages are simultaneous.move a single fader and have it send MIDI CC's 102 and 103 based on the fader position
So
maybe I should say
move a single fader and have it send MIDI CC's 102 and 103 based on the fader position
and add a slight delay to messages on 103
updated my post with a working example. Note this only sends a single 102 msg and 103 msg for each position change of the slider. This should not choke the target.
Interesting, yes I tried yours. Turning off x cut down the number of messages.
actually changing physics of the fader from interpolate to none has the same effect.
your faders ought to work, but don't
I can only assume that the RME software is the culprit.
since
this looks good but doesnt work
16:20:49.801 From Daemon Input 1 Control 10 Controller 102 73
16:20:49.801 From Daemon Input 1 Control 10 Controller 103 73
16:20:49.865 From Daemon Input 1 Control 10 Controller 102 72
16:20:49.865 From Daemon Input 1 Control 10 Controller 103 72
and
this works
16:27:49.880 From Daemon Input 1 Control 10 Controller 103 63
16:27:49.897 From Daemon Input 1 Control 10 Controller 102 63
now to get Lemur to DO this bit of work and delay one of the messages
I'm looking at your clocky library. hmmm that script is red. uh oh.
did you get it working?
anyhow. I wish I could keep at this while you are around but I have to run out for a few hours.
I'm going to test some ideas from the previous post when I get back.
shortly
actually changing physics of the fader from interpolate to none has the same effect.
your faders ought to work, but don't
I can only assume that the RME software is the culprit.
since
this looks good but doesnt work
16:20:49.801 From Daemon Input 1 Control 10 Controller 102 73
16:20:49.801 From Daemon Input 1 Control 10 Controller 103 73
16:20:49.865 From Daemon Input 1 Control 10 Controller 102 72
16:20:49.865 From Daemon Input 1 Control 10 Controller 103 72
and
this works
16:27:49.880 From Daemon Input 1 Control 10 Controller 103 63
16:27:49.897 From Daemon Input 1 Control 10 Controller 102 63
now to get Lemur to DO this bit of work and delay one of the messages
I'm looking at your clocky library. hmmm that script is red. uh oh.
did you get it working?
anyhow. I wish I could keep at this while you are around but I have to run out for a few hours.
I'm going to test some ideas from the previous post when I get back.
shortly
that clock example used to work.... I wonder what changed in Lemur?
Anyway - since your current example that we've been playing with are using MIDI info directly from a variable, you can't (to my knowledge) introduce any delays. To delay one message from another, it has to be done through scripting.
Basic idea is to creating a script with both messages in it and have the script triggered on a frame (you don't need as much delay as a MIDI clock can introduce, I don't think).
The script should store the current frame count and x values so that every time it is called (approx. every 16ms), it can check to see if the fader position has changed (x is different than the old stored value) and if one or more frames have passed (current framecount > stored framecount+1 or 2 or whatever is needed by the target).
If x has changed, send MIDI CC 102. If x has changed and MIDI CC 102 has been sent and the framecount is greater than the old framecount, send MIDI CC 103.
Anyway - since your current example that we've been playing with are using MIDI info directly from a variable, you can't (to my knowledge) introduce any delays. To delay one message from another, it has to be done through scripting.
Basic idea is to creating a script with both messages in it and have the script triggered on a frame (you don't need as much delay as a MIDI clock can introduce, I don't think).
The script should store the current frame count and x values so that every time it is called (approx. every 16ms), it can check to see if the fader position has changed (x is different than the old stored value) and if one or more frames have passed (current framecount > stored framecount+1 or 2 or whatever is needed by the target).
If x has changed, send MIDI CC 102. If x has changed and MIDI CC 102 has been sent and the framecount is greater than the old framecount, send MIDI CC 103.
Hi again
It does sound like the RME software or your transport layer is at fault
The 'simultaneous' midi events should not be an issue, they are of course sent serially in the end
How are you sending the data - WiFi, Hardware?
Checked out the Fireface demo - it responds fine to simultaneous Pitchbend messages
It does not seem to allow any midi mapping so I could not try it with control data . . .
There is however a decent Lemur project that uses the Mackie protocol
It therefore uses the concept of banks of 8 Faders rather then addressing things individually
Easiest way to link two objects is by using the 'alias' feature - right click menu
You can also send 2 ccs easily using one custom_midi using an array as the value - {102,103}
Although I can get it to interleave messages it really does not solve the issue for you
It is not possible to 'delay' the different midi messages by any particular amount (scripting wise that is)
The standard minimum delay between script messages is one frame or roughly 16ms
Although it is possible to send the CCs on alternating frames you will have various side effects
The Faders values will either be slightly out of sync due to various reasons,
Or you will loose time/data resolution because you are basically halving the framerate.
Heres 2 other ways to do it - one sends 2 vals each frame
19:59:23.865 From Daemon Input 1 Control 10 102 77
19:59:23.865 From Daemon Input 1 Control 10 103 77
19:59:23.933 From Daemon Input 1 Control 10 102 78
19:59:23.933 From Daemon Input 1 Control 10 103 78
the other only 1 val . . .
19:59:57.695 From Daemon Input 1 Control 10 102 51
19:59:57.732 From Daemon Input 1 Control 10 103 52
19:59:57.747 From Daemon Input 1 Control 10 102 53
19:59:57.800 From Daemon Input 1 Control 10 103 54
Edit= Forgot the attachment
aliastest.jzml
It does sound like the RME software or your transport layer is at fault
The 'simultaneous' midi events should not be an issue, they are of course sent serially in the end
How are you sending the data - WiFi, Hardware?
Checked out the Fireface demo - it responds fine to simultaneous Pitchbend messages
It does not seem to allow any midi mapping so I could not try it with control data . . .
There is however a decent Lemur project that uses the Mackie protocol
It therefore uses the concept of banks of 8 Faders rather then addressing things individually
Easiest way to link two objects is by using the 'alias' feature - right click menu
You can also send 2 ccs easily using one custom_midi using an array as the value - {102,103}
Although I can get it to interleave messages it really does not solve the issue for you
It is not possible to 'delay' the different midi messages by any particular amount (scripting wise that is)
The standard minimum delay between script messages is one frame or roughly 16ms
Although it is possible to send the CCs on alternating frames you will have various side effects
The Faders values will either be slightly out of sync due to various reasons,
Or you will loose time/data resolution because you are basically halving the framerate.
Heres 2 other ways to do it - one sends 2 vals each frame
19:59:23.865 From Daemon Input 1 Control 10 102 77
19:59:23.865 From Daemon Input 1 Control 10 103 77
19:59:23.933 From Daemon Input 1 Control 10 102 78
19:59:23.933 From Daemon Input 1 Control 10 103 78
the other only 1 val . . .
19:59:57.695 From Daemon Input 1 Control 10 102 51
19:59:57.732 From Daemon Input 1 Control 10 103 52
19:59:57.747 From Daemon Input 1 Control 10 102 53
19:59:57.800 From Daemon Input 1 Control 10 103 54
Edit= Forgot the attachment
aliastest.jzml
Thanks to both you guys.
I'm on a deadline for the next couple of days so I'll be back in a bit.
I'm going to try out a couple of those things before I move on, but in the end, even if it doesn't work,
it's really more of a convenience in the project than a necessity... I do have 2 fingers
Macciza,
You are certainly correct that the problem lies in RME software
I also agree completely in the sense that - I don't get it exactly, as the midi protocol OUGHT to be holding each preceeding message until the previous one is finished F7
I super appreciate your assistance because - thanks in no small part to the RME software wierdness that we're seeing_
I was stuck and severely doubting whether I wasn't just totally wrong in my approach. sorry if I sounded bugged out.
BTW
This is a totalmix thing I'm working on - the older version - not the new totalmix FX but it's what works for my hardware.
I built on that existing Lemur totalmix project you mention.
I'll post it soon in the projects page, because it's got some additional tabs that I find super useful...
I've got another project that's nearly done too.
I'll post these when I have time to write up a description.
I'm on a deadline for the next couple of days so I'll be back in a bit.
I'm going to try out a couple of those things before I move on, but in the end, even if it doesn't work,
it's really more of a convenience in the project than a necessity... I do have 2 fingers
Macciza,
You are certainly correct that the problem lies in RME software
These messagesThe 'simultaneous' midi events should not be an issue, they are of course sent serially in the end
How are you sending the data - WiFi, Hardware?
are going from wifi to core midi and I've tested them with Lemur editor connection ON and with the lemur editor closed.16:20:49.801 From Daemon Input 1 Control 10 Controller 102 73
16:20:49.801 From Daemon Input 1 Control 10 Controller 103 73
I also agree completely in the sense that - I don't get it exactly, as the midi protocol OUGHT to be holding each preceeding message until the previous one is finished F7
I super appreciate your assistance because - thanks in no small part to the RME software wierdness that we're seeing_
I was stuck and severely doubting whether I wasn't just totally wrong in my approach. sorry if I sounded bugged out.
BTW
This is a totalmix thing I'm working on - the older version - not the new totalmix FX but it's what works for my hardware.
I built on that existing Lemur totalmix project you mention.
I'll post it soon in the projects page, because it's got some additional tabs that I find super useful...
I've got another project that's nearly done too.
I'll post these when I have time to write up a description.