Get Values from the Daw + Possible to sync timers to DAW

Hey after finally getting away from the annoyances of the Trial
I would like to get my feet wet some more with MT

My first question is simple: How can I sync timers in MT to the actual BPM and beat time of my DAW?
(The manual only talks about pass thru between two other programs (Live and Traktor) and not how that timing information can be intercepted and used in variables and therefore timers)



The second problem I have concerns getting the actual values of parameters in my DAW (Live).

For this a little background which explains what I want to do, so that the necessity of that information becomes apparent.

-I'm using Ableton Live, the Utility script Clyphx, Bomes MT Pro and a Launchpad
-The goal is: A fade out of a parameter in Live to zero, triggered by a button press on the Launchpad + the possibility to later fade back in to the exact value the fade out started from.
The fading periods should be constant. (say 4 bars)

The knowledge of the value is needed to determine how many steps the timer must take/or how big the steps must be to arrive at zero in the constant fade period given and to be able to return to that exact value it started from.

My plan includes:

Translator to take in button press
Rules to determine the amount of repeats/size of the steps to get to zero according to the actual value of the parameter
timer repeat number based in these values

Timer-Outgoing action to go to ClyphX where it will trigger an action that lowers the value by a set value every time it gets triggered.

Like: 8/SendA >


Fade-in:
Via Shift
The same button on the Launchpad should then be able to reverse this, by changing the outgoing Midi CC to trigger the opposite action:

Like: 8/SendA <

Any ideas how to get the value of the parameter in question?
(First using an encoder to set the value of the parameter which can then be intercepted is not the solution I search for, because even if I would use a direct button to several timed encoder translations and I had used this encoder to set the parameter in the first place, so that I was able to record the value. For the 64 parameters I want to affect that way, I would need 64 global variables to store these values. And as far as I understood there are not that many global variables )

Hi TomViolenz.

We have a bunch of pieces to work through, so let's start one by one, okay? This is going to take a few attempts, but we need to make sure each piece works as expected before we can combine them.

First, we need to deal with the MIDI Clock. You want to create a translator and assign it a virtual MIDI Port. This can be a Port you are currently using, or an unused one, it is up to you. The incoming message is going to be F8. In Ableton you want to open your MIDI Preferences and select Sync for that selected port. F8 is a MIDI clock signal, which sends 24 times a beat. We will be using this to define some global variables and kind of define beats, bars, etc.

What we are going to do is create a global variable which will count every incoming F8 message and reset when it hits 24. You will use a second global variable which will track the current beat (1-4) so you can always define which beat to wait for and which segment of that beat. You could combine these into one large global variable (so 1 would be the downbeat of beat 1, 25 the downbeat of beat 2, 37 the upbeat of beat 2, etc.) as well, if you'd prefer. The translator would look something like:
So what this will do is count every incoming F8 message and then count up every beat. You could assign global variables to 16th notes, 8th notes, etc., depending on how granular you want to get, or just jot down the values and track one big global variable. I would also recommend creating an initialization translator which will set your tracked variables to 0 when the project is opened.

Does that make sense?
Jared

Ok, I think I understood that so far and have implemented it.

I'm having a hard time though to use these variables.

What I would like to achieve is to have the repeat rate of the F8 signal influence the delay of a timer.

This is to make a NoteRepeat that is synced to Live and gets faster/slower if I turn up the BPM in Live.

Translator 1:
on activation of preset

Rules:
g0=0
g1=0

outgoing: none

Translator 2:

Incoming: F8 (virtual port2, as set up in Live to receive midi clock)

Rules:
g0=g0+1
if g0>24 then g0=1
if g0>24 then g1=g1+1
if g1>4 then g1=1

Outgoing: none

Translator 3:

Incoming: B6 ss rr (swallow incoming notes!)

Rules:
gs=ss
gr=rr


Outgoing: Timer (name NoteRepeater)

Infinitely
Initial Delay: ? (should be set to sync to the beat)
Repeat Delay: ? (should be a variable number that results from the BPM and a Repeat rate I choose- for now I have set this to 500ms just to see if it works (it does so far))


Translator 4:

Incoming: Timer NoteRepeater

Outgoing: 90 gs gr



AND the problem, aside from me not figuring out how to program the timer, is the same as I had in the other thread.
If I run the timer at the static 500ms it repeats the notes when I turn the encoder on - GOOD
But if I keep turning the encoder it does't just update the velocity of the repeated notes with gr, it also retriggers the note in-between the repeats. This means the NoteRepeat is variable in its velocity by turning the encoder, but also gives out many unwanted notes. (Even though swallow is ticked)

I must be thinking about this wrong

I think I know where my conceptual problem lies concerning the delay timing and the F8 message.

I don't only need to have the clock signal (periodic oscillation) but I need a reference time that it refers to.
It's great to have 96 clicks per bar, but I can't possibly use it in a timer, if I don't know how long one bar takes to pass.
So, I at least still need a measure for BPM, right?!
So how do I get this?!

Bump

So I had the idea to just assign an encoder to Lives BPM and set it to cover from 0-128 BPM over the whole range, so that one step equals one BPM. Measuring the incoming values of that encoder would allow me to calculate how much time each step of the clock signal actually corresponds to. Thus giving me delay times in ms to work with.


But this is a workaround and I don't know how reliable it would be in a live situation, when I would try to beat match the NoteRepeated beats to beats from other sources. And also it not only limits me to tracks up to 128 BPM but also to a precision of whole BPM steps.

Is this workaround really the only way?

Okay, I think I see what's going on. You don't need to do any math to convert the F8 signal into anything because the translator receiving F8 is already handling all that work. Instead we need to have that signal control other MIDI signals, and we'll do this by assigning it a timer.

In that initial translator I put together, set the outgoing message to Clock Timer with a 0ms delay. Now, every time F8 comes in a timer will trigger, as well as counting variables. So, let's say you want to assign the Delay to fade out at every F8 click, right? We aren't going to worry about resolution or rates right now, just whenever the F8 comes in.

It should look like:
Next we need your Delay signal, right? Since you aren't going to want the Delay fade out to be triggered all the time we will need to assign a global variable as a sort of shift function, which I'll show you below. I'm assuming that the method would be having your Delay set up, and when you press a button it begins fading. Is that correct? I'm going to be guessing at values, but the incoming message for Translator 2 is whatever button you press, and the outgoing message of Translator 3 is the knob that you want to fade out going to Ableton. If it is at all possible to use an endless encoder that would be easiest, and I'll assume that's what you're doing. If not then we can make necessary changes.
So what should happen is that when you press your fade out button the knob should begin fading to 0 at the rate the timer is sending. Does that make sense?

Oh, I think I should have made my first post into two threads. This lead to some confusion.

There were actually two independent questions contained in the first post one regarding the clock signal and BPM, and one how to get values from other parameters out of Live to turn them into variables.

The later one was the one for the fades, and it's probably best to leave that for another time for now, to avoid further confusion.


The clock signal is not wanted for the fades but for a NoteRepeat functionality. I think your answer might apply here too though. (and I will keep it in mind for the fade project too)

I will try to explain again my aim and am hopefully a little clearer this time.

(Are you familiar with Ableton Live btw., I hope so because this refers to many things there.)

I have a DrumRack with 8 drum sounds on 8 pads.

They trigger if they receive Midi from C1 to G1.
For each of these sounds, I would like to have a NoteRepeat that is independent from the other 7 sounds.
So that I can adjust the Kicks to repeat every beat (1/4th Repeat), the snares twice as often (1/8th repeat) and so on.
Then with 8 encoders I want to control the velocity of the 8 sounds getting repeated. With the encoder set to 0 it should be off (or just silent, doesn't matter). Turning the encoders up increases the velocity of the repeated notes (SMOOTHLY - without triggering notes that are between the repeated ones, which is something I have struggled with so far even in my simple static repeats).

Another set of 8 encoders should be able to select the repeat rate that I apply to each sound.

If I understood your last post correctly you suggest using the clock signal indirectly via a 0ms timer to trigger other Midi messages (in this case the Notes).

So in the case of a 1/4th repeat I should just have it trigger each time g0 hits 24.
What I'm a little unclear on is how I could make it switch e.g from triggering every beat (1/4th) to repeat twice every beat (1/8th) which would be if g0 is 12 and 24?!
(In the end I want to be able to switch between 23 different timings from 1/1 to 1/16 triplet, so from every 96th g0 tick, to once very 4th tick of g0)

And as mentioned above I want to be able to update the velocity of the triggered notes by turning another encoder

Ok, I wanted to continue with the project, but I can't get the signal from the Midi clock anymore

The only thing I did was restart MT because it had locked up.

Live is sending, (as shown by the blinking Midi out light) but MT is not showing any activity in the Midi monitor

I tried restarting Live, reselecting the midi port in MT nothing works. Any hints???

Oh well, that's not good.

Restart everything (and if you haven't yet, restart your machine as well) and reconnect the devices together. Weird things can happen, but they definitely shouldn't.

As far as your other post, we can still work through this.

So, we are going to need to build some serious logic into this to get it all to stick. First, you want the drum to trigger when g0 is 1, not 24. The way we built the logic is once the MIDI clock starts sending the downbeat will be registered as g0=1.

We will start with the rate knobs. Each knob is going to have to use a reference global variable to tell your timers how often to trigger. Since you are using endless encoders we don't need to worry about dividing up steps since you are going to just move up and down. You should decide how far you want to turn the knob before it hits the next step. Also, are you going to have visual feedback? That would make this even more pretty to look at, and easy to use.

We are going to need a bunch of timers for this, but what I am curious about is your logic for triggering the repeats. You will have to hit the drum pad first, obviously, but how will you begin sending out the repeats from there? Are you going to hit a Go button somewhere? I need to know so we can build the timer triggers.

As far as the velocity, you only want the repeating notes to have a selectable velocity, but everything you hit with a pad you want to reflect the incoming velocity? Correct? That isn't hard. What you can do is set the position of your velocity knob to a global variable, and whenever the timer triggers the note it will pull that global variable value, instead of a local variable or a static one. And then when you strike the pad you will be using a separate translator which will reflect the velocity of the incoming message as opposed to the knob position.

This is a lot, but I want to make sure it's making sense. Fill in the blanks for me and we'll move forward.
J

Got the Midi clock back

Updating the velocity of the triggered note works as described by you, very smooth!

I think I found a better way than timers though to get to different repeat rates.
It goes like this:
I will start with the one Midi clock translator always outputting to a 0ms timer. And only calculating g0

In the receiving translator I will include math that will transform g0 to g1
And then tell it to exit rules and ignore outgoing action (the note triggering) unless g1 hits a specific value.
(I already tried this for one note and found out that I get the coolest rhythms when I vary the math either for what value of g1 should execute the outgoing message or by varying the line determining g1 for when g1 is turned up by one in relation to g0 )

For every repeat rate, I will will have different math of turning g0 to g1 and I will switch between which math to use via If-then statements and goto labels responding to another global variable that another encoder (the one determining the repeat rate) sets in another translator.

I will make 8 of these receiving translators (and 8 repeat rate translators), each with a different global variable (g2-8) and a different note they output.

Are you going to hit a Go button somewhere? I need to know so we can build the timer triggers.

No this is not necessary, as a velocity of 0 is a note off message for Live. So The encoder that determines the velocity takes care of this.

Unfortunately I have engagements today, so it will have to wait till tomorrow

Thanks for you help so far, I will report back as soon as I have set this up.