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.
Linking or double messaging from a fader
-
- Regular
- Posts: 315
- Joined: 02 Nov 2013 11:19
Re: Linking or double messaging from a fader
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
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
- Attachments
-
- aliastest.jzml
- (7.13 KiB) Downloaded 52 times
iMac 2.8G i7 12G 10.6.8/10.7.2, Legacy Dexter/Lemur, Liine Lemur/iPad2, KMI SoftStep, 12Step & QuNeo , B-Controls, Mackie C4 etc
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
Re: Linking or double messaging from a fader
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.