output MTC based on SMPTE?
I use a MaxMSP tool that reads information from a Pioneer CDJ2000 player and converts this into a SMPTE signal.
Is somebody capable of editing the tool, so it also outputs MTC ? I need this so Ableton can slave to it, and my lightshow can run in sync with the music that is playing.
Here's a link to the tool, at the bottom:
https://github.com/brunchboy/beat-link-trigger/tree/master/doc
Hi there,
If you could be of any help that would mean the world to me! I'm a complete Noob when it comes down to scripting MaxMSP...
I'm using the single SMPTE daemon, and I just need a simple MTC timecode routed to my IAC Bus. No MMC needed.
Thanks !!!!
Hi, yes I use it as a standalone. I use it to send MTC to Ableton and let Ableton slave to it...
Hardwired to IAC Bus 1 works for me, but is it a lot of work to put the possible outputs in a dropdown?
If you want I can set up a dropbox or similar to upload it?
Hi,
I tried out the app and it works really great ! The MTC responds really well to my starts and stops on the CD players.
However, I'm running into a problem that the generated MTC is not in sync with the actual position of the song. For instance if my playbar in Ableton is located at 1min25seconds, and I start a new song from the beginning, the bar doesn't rewind to the actual beginning of the song, but proceeds from where it left off at 1:25... Is there any way to fix this?
Does my explanation make any sense?
I think I understand what You are saying.
The thing is - MTC itself is a stream of frames, but position
gets sent as full frame message which in fact is data exclusive.
I am not using ableton live at all, I tested the standalone which I sent You
with Digital Performer which synced allright and also jumped to
set location.
BUT I didi not receive any data from CD Player, I triggered SMPTE and MTC
by hand, using START button. That buton is set to send data exclusive with
current frame locatioin on every stop and start. But it should also react on start/stop
received via UDP port, right ?
So one should see what is the problem.
Could You try to start playback by hand also ?
Maybe I should send You the patch so that You can debug it.
In the meantime, I will try to set Liuve on one of my macs and se if it reacts to
data exclusive.
I will let You know what results are.
By the way - I looked at the software which interprets CD Player status etc
It should be able to send at least midi beat clock to any destination,
maybe that could also be a way to try ?
Here is download link :
https://files.fm/u/hvvqkjw4
Hi there,
that's amazing you've made this kind of progress in such a short time! Thank you so much already for this.
Ultimately what I'm trying to achieve is really simple (I think):
I want my Ableton to run in perfect sync (both speed, position) with the CDJ signal.
The reason why I want Ableton to run in sync is that my lights are being triggered from within Ableton (thru a DMXis usb dongle). It's obviously quite crucial that my lights get triggered at the exact time :-)
The version I tested from you was already pretty good, in the way that it smoothly responded to my starts and stops. The only thing it was lacking is its exact position sync.
I was also a bit confused by the reset button in the app, which in fact did reset the counter. I was expecting that a reset button would not be visible, since to me there is in fact not a use for it when it perfectly syncs to the position of the CD player.
Do you think you can alter the software in that way so it will also lock to the exact position of the CD player?
I don't know if I could get that work perfectly in sync without having hardware itself.
All I did was taking the miliseconds position that gets generated
by the stuff that was in original standalone, and convert it
to MTC.
I can tell You so far that data gets in through UDP, sets speed and
position for the phasor, which runs on it's own and produces milisecond
based position of elapsed time.
So in between the CD player and Ableton Live is :
1 beat-link-trigger software that translates CD data to UDP
2 reception of UDP values and startup of phasor in maxpatch
3 conversion of phasor ms output to SMPTE & MTC and send over IAC buss
4 Ableton receiving MTC
So if CD and Live are not perfectly in sync, how to find out
where the problem is ? One would have to monitor and compare
source time code and time code at the end of the chain.
What is with SMPTE part ?
What are You controling with it, and is whatever Hardware that
receives it perfectly in sync with CD Player ?
-------------
Could You do more testing and describe more precise
what and how much gets out of sync.
I could not find any MTC monitor in Live, or at least
milisecond Timeline to watch how precise it syncs to MTC.
Hi, I downloaded the new file and tried to open it, but nothing happens... Something's wrong? The first version still works here.
The problem is that You probably extracted the standalone in the same folder as the first one.
Then new standalone got renamed - SMPTE+MTC-1.app or similar.
When that happens, executable in the app can't find the mxf file.
You can delete old one and rename the new one, than it would run.
--------------
In the meantime I had a bit time to spend with Live - I seldom
had such a dislike feeling towards any software...
Anyway, it responds to MTC messages, but it gets rather confused
when it receives fullframe message for new position.
So I have removed it, it runs better without it.
I will send You soon new version which would work well,
or at least as long as You don't change the original speed of playback
too much.
-------------
MTC is not capable of tracing wild speed changes, neither
was SMPT ever meant to do so, but SMPT, being a signal
can handle it better, MTC is a real time midi message,
it is constructed of 8 bytes representing current frame
in H:M:S:F prepended by 241 - this 16 bytes must be sent
in proper order and speed, otherwise it does not work.
To calculate timing for sending bytes is easy depending on frame rate,
but when clock source changes speed rapidly and deviation is high,
MTC can't cope with that.
------------
If You would describe in a simple way what Your Live setup
looks like, what Hardware and software do You use,
how do You control the whole system etc, maybe one can find
optimal way to link and sync everything.
Hi, thanks for the info. The second version was in fact in the same folder. I will put it in another folder when I get home, and give it another go!
I played around with your first version last night and, besides the timing sometimes being off, it really works very well! There's almost no latency, which surprised me a lot. Awesome!
One feature request that would make the process even smoother is some kind of "jam mode" (like https://sononum.net/smptereader has) which makes sure the MTC & LTC keeps running when a short dropout happens. Right now the playbar in Ableton is a bit "jittery" because sometimes there are short dropouts. A jam mode that keeps the signal going (for about 3 to 5 seconds) when a dropout happens would help. Is that possible?
My live DJ setup is fairly simple: I use 2 Pioneer CDJ-2000Nxs players and 1 Pioneer DJM-900 mixer to play the music.
To control my lights and fogmachines I use Ableton and a USB DMX box (Enttec DMXis). My lights are basically being triggered from within Ableton by playing specific midi notes (some notes are assigned to specific lighting presets).
Right now I use a Novation Launchpad to trigger the specific notes, but my objective is to automate the whole process, so I can program my whole lightshow for a complete DJ set.
I use BeatLinkTrigger to pick up the signals from the CDJ players, and your updated application to generate MTC, so Ableton can slave to it and play all my light-cue's on the exact time.
thanks!!
In that case You don't need SMPTE at all, only triggering of midi notes, or whatever
seems best to recall Light presets , on exact time position.
That is a trivial task to do in Max, You can let Live completely out,
the main thing would be to know exactly what CDJ players send out.
The way it is now - there is NO SYNC AT ALL.
The app only gets start/stop position and speed info from the CD Player,
then app creates timecode itself , run by phasor~ .
For short sequences, that could be ok, but over longer time
it would definitely drift appart.
I will anyway try to get time today to send version that should
talk a bit better to live, and please let me know if You really
don't use audio SMPTE, so that I can remove it from the app.
Right now i'm not using the SMPTE signal directly, but I will in the very near future to also sync up videoclips that run from Resolume VJ software. Resolume can accept SMPTE.
I do need Live right now, because every song I play is a a separate Midi track in Ableton which has the programmed light cue's that get pushed to my lights via the DMXis plugin within Ableton. I have programmed some rules in BeatLinkTrigger that send midi notes to Ableton to solo the correct track that is playing (all the solo buttons for all the tracks have been midi mapped)
I would definitely be open to let Live out of the equation, but right now I don't see how that can work for my DMXis plugin... Also, I want to maintain a clear visual overview of my programmed midi tracks while playing.
Do you think the "jam mode" I suggested is possible to implement?
I have the new app ready.
download link :
https://files.fm/u/rdgaf7ex
There are no dropouts in this app, because it is not receiving any sync from BeatLinkTrigger.
The internal clock gets stoped only if BeatLinkTrigger sends stop message.
Please read again my previous post about "NO SYNC AT ALL".
----------
what is different in this version - the Full Frame position message
has been removed, as obviously Live does not like it.
Phasor that runs clock is getting properly "parked" when stop
message gets received from BeatLinkTrigger.
Main problem will remain speed change, that is not going to
work properly via MTC.
One should maybe try Beat Clock instead, it would be MUCH easier
to implement speed changes.
Thanks a lot!! I will fire it up when I get home in a couple of hours.
Can you explain a bit further what the removal of the sync from BeatLinkTrigger will exactly mean? Will this get me in trouble when there are parts in certain songs that are being looped (which is something I do) ?
Can you also clarify what problems I could be running into, speed change wise? I usually perform around 2 hours live. Do you see it realistic that your app will be up for the job for the whole set? And what can I do to get the timing back on track once it drifts off? Will a restart of the app get it back on time?
My tracks vary between lengths of 1min and 10min, and BPM's vary between 80 and 175.
I'm sorry if my questions might sound a bit silly. I'm really a complete M4L illiterate..
Thanks so much !!!
My problem to answer questions properly is that I don't know
what exactly gets sent from the CD Player which seems to be master
timing unit in Your setup.
If each Song that You perform restarts the timer from the beginning
than at least that part will be ok, for such short Songs there should be no problem to stay in sync.
But again - there is no sync coming out of BeatLinkTrigger, at least not in the
implementation of that SMPTE app that I modified for You.
I don't want to be to suggestive, but it is allways better to simplify setups
which have to run on stage.
The way I understand it - Your setup is not really efficient.
You use Live just to trigger lights, but don't send sync to it directly from the
BeatLinkTrigger, but make it through that SMPTE.app, which again
in not hard synced to CD Player, but just runs along in hope
timing will stay tight.
And why not play audio from Live and leave that CD Players ?
Then all would be perfectly in sync.
If You need SMPTE, that could be generated out of Live
via max4live device.
But that is only the way I think about it, whatever route You decide for,
I'll be glad to help You.
-------------
Back to the explanation of sync ....
Real sync is when 2 units share common clock and position.
In case of SMPTE it is absolute position of the tape expressed in
H:M:S:F
MTC is just midi implementation of SMPTE
but will never be as tight as audio SMPTE, because
Midi is serial protocol with all drawbacks that come with it.
Midi Beat Clock - another form of Sync has no absolute time info,
it just sends ticks, meanning progress for one step.
The speed of ticks makes Slave move faster or slower,
and when Master gets stoped or jumps somewhere else
like it is case of Loop, then Song Position Pointer (SPP) gets sent.
That SPP value is absolute number of elapsed 16th notes,
and should be passed to Slave before next tick.
I am sure that Live would be more resposive if slaved to Midi Beat Clock.
As I understand, BeatLinkTrigger is capable of sending Midi Beat Clock,
and if You send that to Live, it will react for sure better to Speed changes.
Hi, I downloaded your latest file, but just like version2, I could not open it. To be precise: The app starts (it appears in my list of active programs), but no window appears.
I tested it in a separate folder, but no difference.
Only the first version you made worked for me, and it still works, even with version 2 & 3 in the same folder.
Am I doing something wrong?
Not sure if it helps, but I tried running the Unix executable file in the MacOS folder, and in the terminal which appeared among other messages this came up: "no interfaces folder, you are in serious trouble!"
I redownloaded the zip myself and it works fine.
So please trash all old versions, and then extract the zip file.
At the end it should be named SMPTE+MTC.app
That stupid message about serious trouble because interfaces
folder is missing is a joke, I removed all interfaces because they
are not needed.
You looked in the package contents so, You can see what is inside.
Yes that worked! I put it in a separate folder but also renamed it, that's why it didn't work. It does now.
I'll test it out with my CDJ players in a bit, but it sure does look promising.
Quick question: You said there is no real sync between BeatLinkTrigger and SMPTE, however when I tested your V1 app, the timecode stayed on track when I played a song that had a looped part in the track (I have certain songs with parts that I loop, until I turn off the loop and the song continues).
Will this still be the case in this V3 version?
Another thing I had been breaking my head about is if it would be possible to have Ableton respond to pitch changes on the CD players. Usually I play my tracks with a pitch up of about 3% (so the songs are played a tiny bit faster), however my midi tracks in Ableton are programmed at normal speed.
check out the app discussed on this page: https://forums.pioneerdj.com/hc/en-us/community/posts/206556026-Sync-CDJs-with-Ableton-Live
It is my understanding this is done with Midi Beat Clock commands.
Do you think this is a very complex thing to also implement in the app? Or Do you think it is better to keep both apps running separate ?
Thank you so much for the work you've already done! You really can't fathom how much you've made my life easier with this app. The workarounds I had to do with the original app (which only generated SMPTE) were horrible and totally unreliable. Right now I'm looking forward to taking your app (in conjunction with BeatLinkTrigger) on stage and perform with it. I'll let you know how that goes :-)
the last version has nothing changed in a way it responds to messages from BeatLinkTrigger.
That means it should adjust to position and speed messages from CD Player.
Something is disturbing me - I tested a lot sync between this app
and Live and tried to alter playback speed as well.
The thing is that smpte~ external is disturbing MTC.
I realised that wenn changing the speed of playback - as long smpte~
object is active, MTC does not react properly to speed change
and produces sort of traffic jam in the midi messages queue.
Removing smpte~ external immediately improved the situation.
Hi, I finally found the time to test out the V3 app, and I have to say that results have been really satisfying! So far I haven't really seen too much of MTC drifting out of sync.. I'm really happy about this!!!
I've been thinking about your suggestion to work with Midi Beat Clock as well. I know that BeatLinkTrigger has the "Carabiner" feature which makes it possible to connect with Ableton Link.
Check the info out here: https://github.com/brunchboy/carabiner
I'm not sure however if Carabiner is also able to send Song Pointer Positions. I tried it out for a bit, and it sure did stay in tempo with the CDJ players, however the exact position was not transferred to Ableton... I contacted the creator of BeatLinkTrigger about this, and look forward to hear if this is possible.
What do you think ?
Did You test it with altering speed of playback?
I think if You don't do any excessive speed changes, but just let
it run steady in certain speed, than everything should be ok.
Running too fast could overload midi communication,
because MTC needs to send 16 bytes for each frame.
For that reason it does so every second frame,
which means with 25 frame SMPTE, sync position gets updated
in 80 miliseconds interval, in normal speed.
That makes it clear that jumping in time over MTC must
produce some artifacts, because it takes 80 ms to receive new position.
That's where full frame message gets into play which in more clever
systems get sent to slave in between MTC Frame messages,
so that slave can prepare in advance for new position.
What I saw , Live does not respond to full frame sysex messages.
------------------
It would be helpful if You would give me some infos on what
information gets out of Carabiner, which I did look into.
You see the original SMPTE.app and all modified versions I did for You
listen on UDP port to just 3 messages:
1 enable = Start / Stop ( received as 1 or 0 )
2 speed = play speed as float / 1. = original speed
3 time = playback position in miliseconds
Then internal clock gets generated and converted to SMPTE and MTC.
----------
When this infos get transmitted, in which polling interval etc
is not clear to me, because I have no Player at hand...
I am not Live user, so I don't know if Live can sync to max4Live device.
If it can, one could receive UDP messages directly in Live, avoiding extra
application in between.
------------
Maybe I should invest a bit of time to get some infos on live and max4live,
even though I don't really use live at all...
I did test a little with altering speed (to extreme measures, even double the normal speed), and results were satisfying. Ableton stayed on track with the song. Not sure if it will stay on track if this happens for long amounts of time, but that's not what I do in a normal DJ set anyways, so it's not really an issue for me... I spoke to James, the creator of Beat Link Trigger about the Carabiner option, and his reply was "Carabiner can’t send Song Position Pointers, but it can sync Ableton nicely with BLT at the level of tempo and beats, and BLT itself can send Song Position Pointers.". I have to look into getting BLT sending the pointers. Programming the BLT (in Clojure) so it sends pointers will be a big hurdle for me, but we'll see how it goes... It will definitely be an even better solution if I can get Ableton to sync via Carabiner, and sending the SMPTE via Ableton in the future is definitely an option for me.
Check the BeatLinkTrigger chat as well for more info on sending the Song Position Pointers: https://gitter.im/brunchboy/beat-link-trigger
There's mention of it in a post from January 31st
Connection-wise, all my CD players are connected to a UTP network hub. That way I need only 1 USB stick plugged in to feed all my CD players. My laptop is also plugged in that same hub via a network cable.
What BLT basically does, is it sniffs the packets that are being sent over the network (by mimicking as it were a CDJ player itself) and translates it into readable information. This is the main screen where all triggers are being programmed: http://11234-presscdn-0-32.pagely.netdna-cdn.com/wp-content/uploads/2017/07/beat-link-triggers.jpg
I am currently in the process of writing a trigger to fire a specific midi note to Ableton so a specific midi track is being solo'd. All my midi tracks in Ableton (which contain the light cue's for all the songs I play) have been midi mapped, and the trigger in BLT fires the correct midi note of the track that is playing, and that way the correct track get's solo'd in Ableton.
This is the screen with the player info I get to see when playing tracks: http://11234-presscdn-0-32.pagely.netdna-cdn.com/wp-content/uploads/2017/07/beat-link-trigger-screencap.jpg It's pretty much an exact copy of what I see on the CD-player display. Once I load a song onto one of my decks, it shows up in the BLT menu, and once I press play it starts playing in BLT as well. BLT picks up those signals. So I would assume it is streaming data all the time.
James of BLT pointed me in the direction of implementing a trigger in BLT which sends over Song Position Pointers, so I can sync Ableton via Link and no additional app is needed. I am already pretty satisfied however with the V3 version of your app, but I'm curious enough to try this new method out.
That's great, I'd be happy to try it!
I can see the beat position in BLT when the song is playing, so I think this should be possible to send yes.
FYI; I use max4live
In the meantime I tried using a trigger programmed by James of BLT to send Song Position Pointers to Ableton in EXT mode, and it works.
However, the song on the CD player doesn't run in sync with the same song in Ableton. I'm fairly sure this is because the trigger sets the BPM in Ableton to the BPM on the CD player, which is not what I want.
Let me try to explain how my files are organized:
Every "song" in my Ableton project consists of an audio file (of the same song that is playing on the CDJ, as a guide), and a midi file with all the notes for my lightshow.
The BPM in Ableton is set to 120, and may never change. So the tracks in Ableton are all in "normal speed". I play my tracks on the CD player with a pitch of +3% (so the song plays 3% faster than normal), so the track in Ableton should also be played 3% faster. The actual BPM of the track in the CD player is totally not important.
Just think of it as that a song played at normal speed on the CD player translates to 120 BPM in Ableton.
I want the playhead in Ableton to move at (normal speed + pitch), not at the same BPM as the actual song in the CD player. Forget the BPM of the songs in the CD player!
Let me explain something - Song Position Pointer is usefull only
when Slave syncs to Midi Beat Clock.
Midi beat clock is a tick which gets sent 24 times per quarter note,
and slave will not move till it receives midi start and running ticks.
Song position pointer only says where to jump on next tick, if
master changed it's position. That is why SPP alone won't do any good.
-----------
I start to understand Your live setup, makes me wonder are the Audio Tracks
in Live there just for visual orintation ?
----------
I have looked into Live internal clock and possibilities to extract or
dictate speed of playback and position.
There are some chances to get everything working.
That's because You don't need to change the speed of playback
while running the Song.
Live understands only bars, beats, ticks and tempo.
But let's stop the theory, I need to know more about
UDP messages sent from BLT. Specifically - is BLT allways sending
current position in miliseconds, or does that happen only when
trigger gets fired ? I mean I could imagine that when You start a song
first trigger has Song Name, ID or whatever sent to live, so that
correct Track goes Solo, than /enable 1 speed/1.03 /time 0.
gets sent via UDP - that info is than received in SMPTE+MTC.app
to start the clock, set the speed to 1.03 and Song position to 0 ms.
When You loop a portion of a Song than probably on every Loop
Start Point message with new /time nn in ms gets sent via UDP.
Am I correct about that ?
--------------
In case of having m4Live device listenning to UDP from BLT,
it could receive above infos, set BPM to 120. x 1.03 = 123.6
and instruct Live to play from position 0, or 1.1.1 which Live takes as beginning.
At same time one would generate SMPTE based on current
play position.
That would all work ok, if Audio Files in Your Tracks also respect
changes in Tempo and play faster.
-------------
I'l send You m4live device to peek into data comming over UDP
from BLT. Don't run SMPTE-MTC.app at same time.
Play one of the songs which has Loop inside, I wan't to find out when and how often
data gets transmited. You'l see by blinking at apropriate places.
Another absolutely ridiculous thing in Live is a missing pause button.
One can overcome that in max4live device, but I am really curious why is that missing.
Thanks, I will test the UDP app out tonight!
-----
You are correct, the audio tracks in Live are solely for visual orientation. It makes it much easier to program the midi track with my lightcue's if I can see the audio track.
-----
I would assume that BLT is always sending current position (I could be wrong though), since the generated MTC of your V3 app stays on track when I play a song that has a loop. The audio in Live is a bit "jittery" when in the loop, could be smoother, but basically it works how I want it to work.
Let's wait and see what You discover.
amxd is made in Live 10 I hope You can open it.
I have done some preliminary direct connection simulation BLT - Live
via UDP and it runs very well.
BLT Should send current position in Beats whenewer Looping traqck
is involved.
Spending a bit time with max4live discovers many strange things
and unexpected differences between GUI and live.Api.
So for example soloing a track from GUI mutes all other tracks,
if one does it by live.object call, allready solo'd tracks remain solo'd.
Setting new song position from live.object does not work if one
starts stopped playback, if one changes it by hand in GUI transport,
then it does.
It is really frustrating, I have a feeling that guys at Ableton and Cycling did not
really think it through.
Hi, I tested with the UDP app, but couldn't really get it to work (could be my fault though).
However, with the trigger in BLT activated that sends Song Position Pointers, I can see via a Midi Monitor that there is a continuous stream of Clock messages sent from BLT to my IAC bus. I counted them, and there were about 64 clock messages pér second.
Here's a screenshot of that stream of messages: https://ibb.co/mkde9n
Does that help you in any way?
Ok, then I will send You standalone to watch UDP from BLT.
From the screenshot I see a weird behaviour - clock
being sent 3 times at same exact position and not being steady ?
Something must be wrong there.
But anyway, the way You described how You want to use the sync,
midi beat clock will not help You, because in that case CD Player would have
to control tempo.This is your words:
I want the playhead in Ableton to move at (normal speed + pitch), not at the same BPM as the actual song in the CD player. Forget the BPM of the songs in the CD player!
That makes midi clock and song position pointer useless.
You want live to allways move at 120 BPM + calculated added speed.
But once You put it into Slave to external midi clock mode, tempo is
set from the speed of ticks.
If You could make BLT to allways send midi clock 120 + added speed,
not respecting the BPM of Songs, then it would work,
but then You will have to programm Loop points based on ms
and not beats, and then quantise the position to nearest 16th note.
That because SPP is number of elapsed 16th notes.
1 tick = 24 fractions of quarter note.
In tempo 120 that is 500 ms for a 1/4 note / 24 = 20.833333333333333 ms
per tick, 1 16th note is 500 /4 = 125 ms, which would be time grid
for loop positions in all songs. If the song was done originally in tempo 80,
then loop points would be shit.
------------
UDP check download link:
https://files.fm/u/9cupsjw2
I tried running the UDP app. It's a bit of a mystery to me what it exactly does but anyway:
When I play a song that has a loop, following happens:
Once I get in the loop, a couple of dots start blinking yellow. From left to right it's dot #1, #3 & #4.
I presume they blink every time the loop restarts.
There are 3 timers at the bottom, the 2 to the right start returning values fluctuating around 165. Both values of timer 2 & 3 are identical.
The value of timer 1 only changes when I start/stop a song. Values are mostly around 4000.
I finally found the time to thorougly test your app again, and it seems the timing is running out of sync after some time...
I asked James of BeatLinkTrigger if he could describe what information (speed, position, ...) is being sent from BLT, and his answer was that BLT basically sends what the user has programmed in the triggers... (see code below)
I also tested again with the SMPTE Max app that is in the BLT user guide, and to me it seems that this app is pretty much exactly what I want, it's only the "wrong" kind of timecode (SMPTE instead of MTC) that is being generated.. I played around with it, by playing tracks, and changing the pitch of the tracks during the song, playing loops, ... and the SMPTE timecode is staying in sync.
I can see in my Midi monitor app that a /time and /speed message is being sent out whenever I change the pitch.
In my Beat Link Trigger setup expression, I have following programmed, which picks up the behaviors and sends the appropriate message to the SMPTE app:
========
(let [client (osc/osc-client "localhost" 17001)
handler (reify org.deepsymmetry.beatlink.data.TrackPositionListener
(movementChanged [this update]
(overtone.osc/osc-send client "/time" (int (+ 0 (.milliseconds update))))
(overtone.osc/osc-send client "/speed"(float (.pitch update)))))]
(swap! locals assoc :smpted client
:handler handler)
)
=======
the SMPTE app is available for download here: http://deepsymmetry.org/media/smpted.zip
and an extensive explanation of how the app works can be found here: https://github.com/brunchboy/beat-link-trigger/blob/master/doc/README.adoc#smpte-linear-timecode
in the userguide is also a link to the patch that builds the application.
Do you think you could look at that app/patch, and alter it in a way so it will send MTC?
I really feel that a solution is real close on the horizon, and I can't stress enough how grateful I am already for the help you have been so far tackling this problem. Obviously all the credit goes to you for this!
I have told You before that the way original app worked, there is no real sync
and only start/stop /speed and position if it changed were sent out.
Pleas read the following lines carefully, and make sure You understand all:
---------------------------------
The app I made for You is just a copy of that SMPTE.app from BLT page
with added MTC output.
In theory, it should behave exactly as original, BUT -> I found that smpte~ external
which is used to generate SMPTE Audio Signal is disturbing the timing
of the MTC.
If I removed smpte~ from the app, then it all worked smoothly.
That's why I came up with the idea of receiving osc messages
directly into Live and control the trasport of live with it,
and then generate audio SMPTE for Your other sync needs.
That would mean no need for MTC generation, only position update
from time to time, which at the moment takes place only
on Song Start and Loop restart.
But to do so I need ALL infos. I need to know exactly what gets sent and when.
What hapens if Song comes to it's end, what if You stop it manually, etc etc.
I have made in the meantime max4live device that could replace the standalone
SMPTE+MTC.app, but could not finish it without test results which I asked You to do.
So if You want to continue with this, we need a better and faster communication.
---------------
The needed stuff :
1.- Song Number, Speed and Position (0) infos should be sent when a Song gets loaded
into player, that will be used to stop any playback if it was running,
park trasport to 1.1.0, "SOLO" the track in Live containing Light automation
and whatever else needed.
2.- Play Status ( enable/ 1) , Speed and Position must be sent on Play start,
and LOOP turnover,
Stop (/enable 0) and current Position if Song gets stoped or paused.
3. Maybe resending of play position would be needed in some steady interval
to keep Live synced over longer period of time.
-------------
I also need info about Live version that You use.
------------
Hi, will try to be as accurate as possible. First a question: Can you describe in what way the smpte~ is disturbing the MTC? Any chance you could make a version with the smpte~ included, so I can test it and see how it goes with my setup?
--------
Whenever I load a song, or change the pitch during play, both a /time and /speed message is being sent via OSC (see the code snippet in my previous message). If you want I can make a video of it, so you can see what happens when I load and play a song. The solo'ing of tracks for my light automation happens in the trigger, and this is working how I want it to be. I have an array of tracks in my global setup expression, and each track has an ID (between 1 and 127, a midi note), and a channel. So once a track gets loaded/played that is in the array, the corresponding midi note and channel gets sent to Ableton where the midi note is mapped to the solo button of the track. I would prefer to keep the song number out of the app and let BLT handle this (it works, so I prefer to not change it)
--------
Don't know if it could help, but there is a code snippet available in the Beat Link Trigger chat group which sends Song Position Pointers, and even handles loops and all. It's quite lengthy to post here, so please take a look here: https://gitter.im/brunchboy/beat-link-trigger and see the post of James Elliott of January 31.
let me know if this is interesting to use? Then i will implement the trigger in my setup.
--------
The exact trigger I currently use to feed the SMPTE app is here: http://deepsymmetry.org/media/SMPTE.bltx
I suggest you inspect this trigger, since to my feeling it is working how I want it to work, and makes sure the SMPTE is running smoothly and in sync.
--------
I can CONFIRM that enable 1 and enable 0 messages are being sent on start/stop of a song. As stated above, this trigger can be extended with the code snippet that sends the Song Position Pointers if needed.
--------
I use Ableton 9 suite.
The answer to the smte~ disturbing MTC :
Original SMPTE app is generating a clock using phasor.
That phasor is controlled in speed and position in ms from values received from
BLT.
Output of that phasor is fed into smpte~ external, which then produces Audio signal.
The same phaser output, which counts in float ms values I am using to create
MTC clock and send it to Live.
MTC is being disturbed if one changes speed during playback, in a way that it would loose
position, or would not react to speed changes. It definitely is related to generation of SMPTE
because if I remove it, and use just MTC things get better.
But the important thing for You to understand is that MTC, run like this is not a good way to sync BLT and Live.
The main reason is that SMPTE app is generating own clock, and not slaving to
BLT, only receives when to start, from what position and with what speed.
So I would suggest to bypass that SMPTE-MTC app alltogether, and to send
that infos directly from BLT to Live.
----------
What makes things a bit complicated is that You are not using real BPM
in all that tracks in Live and sync them to real BPM of each song, but want to
run neutral 120 BPM + added speed.
That makes midi clock and song position pointer unusable, as well as live link approach which is bar and beat based, and not absolute time.
One has to stick with ms position.
----------------
I will send You a patch and max4Live device that will sync Live transport
from BLT, using same values as SMPTE.app did.
enable 1 or 0 for start stop, speed $1 as percentage, position of playback in ms.
In order to run this You have to programm triggers for Loop
markers in ms.
As You stated in Your previous post, You don't change speed of playback
while running a Song, only set it before a Song starts.
Download Link :
https://files.fm/u/mhmjb4ps
SMPTE.amxd is programmed as Instrument.
It receives 3 values from BLTm just as SMPTE.app did
/enable 1 or 0 to start / stop Live Playback
/speed as float to scale Live Tempo
/ time as position in ms -> sets Live Play position
Just don't start live transport manually, BLT will do it
with enable command.
Live should be set to internal sync.
Generation of Audio Smpte Signal can be switched on or off.
-------------
If You can't load that device into Live, You can
use SMPTE.maxpat to build it new.
-------------
If it will sync over longer time, is hard to say.
Maybe You need to send time value from time to time
to keep it in sync with the CD Player.
--------------
If there was a chance to run CD Player and Live without real sync,
this would be the most efficient way, because no other app is in
between BLT and Live.
Hi,
Just played around with this version, and for the most part it works GREAT !!!
It responds really fast (low latency), stays fairly well in sync, handles pitch changes good, and it handles loops good!
REALLY HAPPY WITH THIS !!!
Few things:
- Whenever I pause a playing track, and press play again, my Ableton track restarts from the beginning of the song (instead of carrying on from where it left off). Not sure if this is caused by the trigger or by your app.
- Small feature request: The button to turn on/off SMPTE is good. for the SMPTE signal (which I use to feed Resolume VJ software) a dual SMPTE feed would be ideal (one signal for the left deck, another for the right deck). Is there a possibility for generation of 2 SMPTE feeds based on what deck a track is playing (and have a dropdown menu to select where the feed should be sent to)?
I can imagine that other people will be interested in this as well, but it's definitely possible other people will only need 1 SMPTE feed for different purposes, so maybe 2 versions of the app (one with 1 SMPTE feed, another with 2 feeds) would be ideal.
I'm gonna test it some more tonight, and will let you know if anything else comes up!
THANK YOU !!!!
I am glad it works.
Now to stuff to be done :
1 - You did not say that You pause the Player.
That makes a big difference.
I have to change things to make it work, but it is a bit unreliable
because one needs to bundle continue play position with last known position.
2- I forgot to include SMPTE frame rate selection.
That will be done in next version.
This with second SMPTE Output is definitely possible, but You have to explain this better.
How should I know which Deck is playing ?
You see , You can send any info over UDP to this plugin, even info on which deck is playing.
That could switch SMPTE output to only left, or right output of the track.
No need to generate another SMPTE signal.
Could You send /deck 1 or /deck 2 message from BLT to
UDP when a Song starts depending on which deck is playing ?
---------
And one last but not least important thing :
I hope that You understand well the difference between REAL SMPTE sync
and beat based Ableton.
I will give You an example, please read this few times :
I am using plugsync~ object to capture Live Transport status.
It can display all that stuff including Tempo, Time Signature etc,
but in terms of play position, there is only Bars, Beats and TICKS,
that means no real time in miliseconds.
There is even samplecount output, but that one is a joke,
because it runs on it's own,
and has nothing to do with Live playing position.
Anyway, to get milisecon position, one has to calculate raw ticks/tempo
and get current position in ms.
BUT NOW COMES THE SHIT :
Live has no tempo map, if You start a Song with 120
and let it run for 20 Bars, ticks calculated to ms will show 40 seconds of elapsed time.
If You now speed up the tempo to 103 % , ticks to ms calc will now display 38.83495145631068
seconds, meaning that SMPTE output will jump back in time.
That means - You can only set speed on the beginning of the song,
and have to leave it unchanged.
Played around with it some more and here's some things that came up:
- When I start song B at the end of song A (for instance during a fade out of song A), song B is not in sync anymore but running behind.
When I press play on track B during a fade out of song A, the master player is still deck A, and it only switches once track A is completely finished. I've got a feeling that if I start song B for instance 5 seconds before the very end of song A, the sync is also 5 seconds behind. When I wait for track A to finish completely before I play track B, the sync stays intact.
So my best guess is that something gets messed up once a track starts playing while the other deck is still the master deck.
- I have a feeling that the sync isn't perfect either when I start a song not from the very beginning of the song. For instance I have a couple songs that have an intro which I don't want to play, so I cue the song right after the intro, and that's where the song starts playing.
Another feature suggestion: The possibility to set an offset time (in miliseconds, for instance with a draggable bar to set the exact time offset) to make up for latency. In no way a priority!
About the split SMPTE: In this setup I install a separate trigger for the left and right deck, and on start/stop of a track on the left deck a /left/enable 1 or /left/enable 0 message is sent (and for the right deck the same thing). You can check the LEFT trigger here: http://deepsymmetry.org/media/SMPTE-Left.bltx
I bet I can customize the message that is sent to whatever you want it to be.
I've read your explanation about the SMPTE sync a couple of times, and I believe I understand. The fact that I can only set the speed of the song at the beginning is not a problem for me, I never change it during a song, and for about 99% of the time when I DJ, the speed stays around the same value (pitch +/- 3% faster)
All this with Song A , Song B, fade in or fade out...
You have exact facts on what gets sent over UDP,
at least the part which was included in the original SMPTE app.
I don't know of any other values than :
/enable 1 or 0 = 1 starts the Song from beginning, 0 stops and rewinds Live to beginning
/speed as float multiplies Tempo
/time sends current CD Player position in ms
What both CD Players are sending, and what BLT is sending when Master Deck changes ?
I have no idea, maybe Song A sends it position at the end,
and that overrides infos being sent from Deck B ?
Live has only 1 transport, and can not play synced to 2 Decks at same time.
So You have to arrange Your CD PLayers, BLT and whatever in use
so that Live receives correct info in right moment.
You don't need to rename any of the values in the triggers,
just give me exact names and what they should do.
It is not helping if You give me infos on what You really need
in so small portions, because it leads me into wrong direction.
In the beginning there was no mention about pause, crossfading
tracks etc
So let's nail it down and make a proper plan on what is needed.
--------------------
Live Transport has no Pause function.
There is a way to do it, but I have to make further tests, to make sure that resuming play starts from current position.
If You rewind the Deck to lets say 16 Bars, to start a Song,
then You have to send the position again, after starting playback.
That's unfortunately how Live transport behaves.
------------
This is all problematic because in "normal" way, one would
set the REAL BPM for each Song in the CD Players,
use REAL BPM on each Track in Live, and sync Live using REAL Midi Beat Clock
and Song Position Pointer.
You decided to go other way, ignore REAL BPM in both CD Player
and Live, and so disabled the possibility to use either Beat Clock, or Live Link
feature, which is also Bar, Beat, Tempo based.
-----------
Running 2 machines (CD Player and Live) each running it's
own clock, and just realigning the position of Live from time to time
is not going to give You tight sync.
But it might get as close to be still usable on stage,
if You use triggers in right way, and update current time of
play position more frequently, instead of just on Song Start and Loop turnover
Just tested Pause -Resume option, it works ok if /enable 1 and /time nn get sent
immediatelly after each other.
It is necessary to send that on every song start, loop restart,
resume after a pause etc.
Also You need to send /enable 0 on every stop / pause.
***** not if Song crossfade is taking place ****
That will solve the position problem when resuming after a pause.
----------
The problem with crossfading 2 songs will not be easy to deal with.
When I press play on track B during a fade out of song A, the master player is still deck A, and it only switches once track A is completely finished.
Does that mean that Live should just continue to run till Deck B becomes master ?
In that case, if Deck B would sent it's data at the moment it becomes master,
Live could sync allright to it.
The sequence should be : /enable 1 /speed nn /time nn exactly in that order.
How You deal with soloing of DMX tracks, and when do we start SMPTE is another question.
If You could agree to only play crossfaded Audio from Decks, and make
Live switch tracks only when master deck changes, respecting new master's
Speed and Position, we could say it would work.
That could also switch SMPTE destination.
But previous Master Deck should not send /enable 0 when it finishes fade out
because that would stop Live.
Triggers /left/enable 1 or /left/enable 0 as well as /right/enable 1 or /right/enable 0
could be used to switch SMPTE Audio Output, but not for Live Playback,
because Live has only 1 Transport
Here is updated version download link :
https://files.fm/u/au5afn5g
SMPTE-2.amxd
has pause - resume option, if You send /time immediately after /enable 1
Same should be done on Song start, Loop restart etc
/left/enable and /right/enable do switch SMPTE left or right Audio Output
Master SMPTE Switch and 25 or 30 FPS selector params are stored into Song,
as well as Offset 0 - 100 ms.
Offset forwards Live play position by that ammount
to compensate delay introduced by UDP.
---------
Let's see how that works
Well what I need, is really simple: I want the Ableton transport to be as sync'ed as possible with the playing track on the master deck. That's really all I want. I know it might feel like I'm always coming up with new things in small portions, but to be honest, it's really not.
I know by now that it's not REAL SYNC and all that, and I do understand that there are limitations in the whole sync project, but ideally I want the sync that you created to be as tight to the playing track as could possibly be achieved. And yes, that includes staying in sync when looping, pausing, crossfading, changing pitch, ... Simply a (nearly) perfect sync to whatever is happening on the master deck is ALL i want.
-----
At this point I'd rather like to stop focussing on (dual) SMPTE generation, and put all the eggs in the basket of a better MTC sync. Once the MTC is a bit better, and comes to the point where I can safely test it out in a live environment, then we can think about expanding the app to also create SMPTE. But right now, the focus should be syncing to Ableton.
-----
Right now I have my triggers in BLT setup in a way that Song Position Pointers are being sent continuously during play. I'll monitor it tonight to see if the SPP's stay in sync when crossfading songs (and thus switching master deck from one deck to another).
This trigger is listening to the Master deck, which generates 1 stream of SPP's, and Ableton should sync to that. Is it possible to lock the Ableton transport to whatever SPP is coming in? Or do you have a better suggestion on which approach will work the best?
PLEASE READ the trigger I am using to generate the SPP's here: https://files.gitter.im/brunchboy/beat-link-trigger/eZPv/Ableton-Beat-Jumps.bltx
The trigger has a variable 'max-beats-between-spp' which is currently set to 16, but this can be changed to whatever you want it to be.
-----
QUESTION: Ideally, what info do you need to be sent out from BLT to achieve the best possible sync in Ableton? Do you need lots of SPP's? Certain OSC messages during the song? Midi messages of any kind? Help me understand what you need, and I'll try to help you in the best way possible. I feel that we're really close to perfecting this, let's do it !
BUT READ THAT TRIGGER FIRST!!!
I did look in that Trigger right now.
Song Position Pointer is bound to elapsed 16th notes.
So it is absolutely dependant on BPM.
If You have a Song in the CD Player, and I guess You did
programm the real BPM into it, and if it were 112,
then 1 16th note would be exactly 133.928574 ms long.
If you want to jump to beginning of bar 5 in 4/4 it would be 64 elapsed 16th notes
with total length of 8571.428736 ms
If You send SPP 64 to Live, and it is set to 120 BPM,
then Live would jump to 64 x 16th notes in Tempo 120,
which would be 8000 ms
---------- I hope You understand this.
This SMPTE.amxd is not listening to SPP, and if You set Live to slave to Midi Beat Clock,
Live will simply not run, because nobody is sending a midi clock to it.
So Your only choice now is to send time in ms.
Please Test this SMPTE-2 version, and if You feel that it is not tight,
try sending position in ms every 10 seconds.
Crossfading - well this one You have to solve yourself, as I explained
in the previous post.
I tested SMPTE-2.amxd and here's my remarks:
Sometimes, about half the time, the transport in Ableton stops playing when I start a new song on the other deck (while the first song is still playing). So whenever the master deck switches from one deck to another, the transport stops. But when I pause the track, and press play again, the transport is back on track and the position seems pretty accurate.
This transport-stopping behaviour wasn't a problem in the first version of the app.
I've got a feeling that when a track starts on the other deck while the first song is still playing, and the pitch of the second song is much higher or lower than the first song, the sync is off. It's almost like the app still thinks that the pitch of the second song is the same as the pitch of the first song.
The pause/resume option that you included works very good. Strange thing though: When I pause a playing track the transport jumps a little bit forward. When I resume the track, the transport jumps back to the correct position.
Here are few infos that might help You to program the triggers:
One can start Live Transport from max4live by 2 kinds of messages:
As first : {set is_playing $1} message allways restarts Live from beginning
when /enable 1 message gets received from BLT.
call continue_playing and call stop_playing should actually pause/resume
Live playback, but that does not work as expected, at least not in Live 10.
To make Live really start from paused position, one has to resend the position in ms from BLT immediately after the message /enable 1.
Live will than start from set position.
The gap between /enable 1 and /time nn is actually first sending live to beginning of the Song and then forcing it to update position, if the gap is small enough it makes no audible jump.
-----------------
In first version of SMPTE.amxd I used {set is_playing $1} message,
because I did not know that You want to pause/resume the playback.
SMPTE-2.amxd is using call continue_playing and call stop_playing
As I posted in previous post, every /enable 1 message MUST be followed
by /time nn message, even if You Start Song from beginning, or Loop the Song
-----------
The problem You have now with 2 decks is that they both send
/enable 1 or 0 to indicate start/stop and that simply stops Live
whenever /enable 0 message gets in.
You must rethink the way Decks send that infos, and also You need
some kind of plan how to deal with crossfading Songs.
For example a playing Deck should not send /enable 0
if another Deck starts Playback.
Can You set such a Trigger ?
If not, then we have to deal with that problem in the max4Live device.
We could ignore message /enable 1 or 0, and use only /left/enable
and /right/enable messages.
Than I could set a gate that accepts stop messages only from
the last started deck.
-----------
The thing with crossfading Songs is another story, I am not sure
that I understand 100% how Your setup runs in Live.
Here is what I understood, so please correct me for any misunderstood part:
- each Song in CD Player has a counterpart in Live
-when a Song gets loaded in CD PLayer, it sets that Song in Live to Solo, before the playback starts
- Song contains same Audio File as CD PLayer for visual orientation, and DMX data to control lights, in future SMPTE signal is going to control Video Playback
--------
That is all fine, but what do You do when one Deck is fading out, and another Deck starts ?
First Song is controlling position of playback, so Song 2 has 2 options :
1 - to play from current position - which makes no sense
2- to wait till Deck 2 becomes Master for BLT, and then start Playback from
that position, and change speed if speed is different than it was in Song 1.
If crossfade was 5 seconds, then Song 2 would have to start form position 5 seconds.
And it should not be set solo before that point, meaning that midi message
to solo that track should not be sent when deck 2 starts playback, but when it becomes Master
---------- I can give You exact order of messages needed to make a good transition
As far as I know, live can not have 2 independent Transports, and run 2 Songs
independent in time and speed.
That means that crossfade period can only happen in the Decks,
Live has to hard switch between the 2 Songs at some point.
------------
So how do we go on ?
Does the info above help You to decide ?
I'm not sure a trigger can be programmed in a way that a deck doesn't send a /enable 0 message whenever the other deck is already playing. I think this needs to be handled in the M4L device.
About my setup:
each Song in CD Player has a counterpart in Live: Correct, to be more precise: Each CD track has 2 counterparts in Live: the same audio track in Ableton (as a visual guide), and a midi track with my light cue's. All these tracks (right now it's about 100 tracks, 50 audio & 50 midi) are DEACTIVATED by default (so they are all grey instead of yellow). Whenever I LOAD a track on my CD player, nothing happens.
When I START a track, the activation expression in BLT sends a midi note to Ableton, which is mapped to the Activation button of the counterpart tracks so they turn yellow. In the beginning I had them mapped to the solo button, but as it turns out, mapping them to the activation button instead works better for me.
Whenever a track STOPS (either by manually pausing it, or when the track reaches the end), the deactivation expression in BLT sends the same midi note again, which effectively deactivates the audio and midi track again. The activion midi note will only get fired when the deck is master, or BECOMES the master. So when I start a new track during the last 10 seconds of the first track, the master deck will switch at the end of track 1 (or when I pause it), and the activation expression to send the midi note of the new track will get fired then.
About how I play:
It's really not very complicated. I play songs, some have loops, most have not.
Most of the times I start the next song before the first one stops, Because obviously I want a continuous stream of music. If I would only start the next song when the first one has ended, there would be a silent break between every song. so the tracks get MIXED.
Most of the times I start the next song on the last drumbeat of the first song (which is definitely not the same as the END of the song!).
I have some preprogrammed cue's programmed in my CD tracks, and I usually start the song from the first cue in the track. Not all the music in my tracks start exactly at 0:00:00, some songs have some silence in the beginning.
About how I feel what is going to work the best:
I think we are overcomplicating things a bit. My gut feeling tells me that a Midi TIMECODE of the master deck would still work the best for my setup. Basically how I see it, is that I still feel that the original SMPTE generation app on the BLT is very accurate and in sync to what is happening on the CD players. Honestly, and please don't hate me for this, all I really want is the exact same app, but have it send MTC instead of SMPTE, so I can have Ableton slave to it. I feel that in a timecode setup, timecode is being generated for all tracks, and whatever deck is the master deck, that timecode is getting sent out. This effectively eliminates problems like sending (or not sending) correct /enable messages and all that. If the timecode is accurate to the track playing, and is correctly getting translated to what Ableton needs, the sync in Ableton I believe will be spot on.
HOWEVER: If you feel that the same level of sync accuracy can be achieved through your UDP app, without overcomplicating everything, I'm all for it.
Sure, having MTC sent from that SMPTE app would be the easy way,
but You never did really sync Live to it, simly because it was not possible.
I explained You why MTC and smpte~ in same app did not work properly.
I am also more towards as simple as possible solution,
I could send You app that works like SMPTE but generates ONLY MTC.
That will leave You with the problem of switching decks, but that's it, not my problem.
I will send You this app in short time.
To say it again - ONLY MTC will be generated, exactly the way original app
generated SMPTE.
Then You can have separate max4Live device to generate SMPTE based on Live transport.
------
And please don't understand this as me not being interested to find a better solution,
or tighter sync, and solve that deck switching problem in max4live.
But You have to say if we should go on with that, or MTC.app would be
good and final solution.
I'll be back soon.
Download Link :
https://files.fm/u/s68f27mw
Port Number, Frame Rate and Midi Out Port can be stored.
All other item on the screen only display what is being sent fom BLT.
MTC is listenning to only 3 thing from BLT : enable, speed and time.
Whatever gets in, gets sent out in form of MTC.
clock is generated absolutely same as in original SMPTe app.
---------------
You mentioned a need for latency compensation, You probably
mean time from CD player start till info reaches Live.
MTC will introduce more delay than just UDP because MTC gets sent only every 2 frames,
there is no way I can change it.
Only way I could make any compensation would be to offset time
so that Live does not start from set position, but forwarded by needed latency length.
The proper way would be that CD player sends it's status to BLT, and starts own playback later.
Yes, I'd love a standalone app that generates only MTC (preferrably with the choice of IAC bus to send to, and a timecode offset like in your last app), to which Ableton can slave to in Midi Timecode mode.
Since the dual SMPTE timecode is used for an entirely different application (Resolume, which can read 2 SMPTE feeds simultaneously), and separate triggers in BeatLinkTrigger take care of that, I have no problem at all that the MTC and SMPTE is handled by separate applications.
If at a later point the MTC and SMPTE application can be united into 1 that does it all, I'd be very happy to use it, but right now my primary concern is an MTC generating app that syncs well to Ableton.
As I said no way MTC and SMPTE in same app.
I will add offset in ms, and send You new app in a minute, You can ignore the
download link above
here is version with offset :
https://files.fm/u/d8nau8fq
offset gets stored together with port, midi out and frame rate
Great, will try this out asap and let you know.
I reread your statement about the MTC being disturbed by the smpte~: Am i correct in saying that the MTC will run smoothly just as long as no speed changes occur during the song?
Because that's not really a problem for me, I don't do pitch changes during playback at all
I am not sure if it will run smoothly.
I think the reason they fight each other is that SMPT external is running
with higher priority than midi, and when Speed Change comes in, or sometimes even jump in time,
Midi gets stuck, sometimes for shorter, sometimes longer period.
I am sorry but there is no way I could improve this kind of sync.
It will never be as fast as direct connection BLT via UDP to live
And don't worry about SMPTE, one can easily make max4live plugin
to send it out.
The main thing now is to see if Live can run ok with MTC alone.
And can you explain what you would need from BLT to accomplish the same level of accuracy via UDP which we haven’t achieved up to now?
Do you need SPP’s? Anything else?
In terms of sync over longer time - that could be easily solved by sending position in ms from time to time, maybe in 4 bars interval, maybe even longer. That part is problematic in both versions in exactly same way.
The main problem with direct BLT -> UDP -> Live is to organise triggers and messages so that Live knows what to do.
As I asked You in previous mail, give me a plan how to switch between Songs,
how to crossfade Songs.
I need to know what each deck is sending out on whatever action You take.
That can't be complicated to answer.
CD Players are surely behaving nicely in between themself
and do nice crossfades etc, but the outer world has to know what to do.
Which Song should be in front when You crossfade ?
I mean which DMX Control Track is in charge, and in the future -
which Video is going to be seen during the transition ?
Stuff from the Song that is fading out , or new Song ?
In case of new Song, Live would have to rewind and start from beginning when You hit the crossfade button, in case of allready running Song, Live would have to wait till 1st Song stops, and then switch to new Song, starting at position where the Song is at the moment, and also adjust to new speed if it were different.
You call this complicating things, but for me it is essential to know what to do.
If all that would be set and clear, than I could see how to go about solving problems with Live Transport, how to set gates for enable messages from different decks etc.
------------------------
Did You try to crossfade Songs using MTC only ?
I think you are confusing the video part with the lighting in Ableton. MTC is for Ableton, to trigger lights, and nothing else. SMPTE is for Resolume, to sync video. 2 different, unrelated things. For Ableton: At ALL times, I want the track playing on the MASTER deck to be in charge over everything.
Let me rephrase that:
For Ableton, the only thing that matters is 1 track playing, and that is the MASTER track. The other track on the deck that is not the master deck, is of no importance. Since Ableton only has 1 transport, it should be synced to the 1 master track. There is always only 1 master deck on the CD players, never 2. There is no way to predict when the master deck changes from one deck to another, because I don't know when I will start the new song when the other one is still playing. It could be now, but it could also be in 5 seconds, could be really anytime.
For SMPTE: Much simpler setup: There are 2 separate BLT triggers, one for each deck, that generate SMPTE whenever a track is playing. Those 2 streams of SMPTE go into Resolume. This works right now, and doesn't need any change at this moment I believe. From my basic knowledge of BLT, I think the activation expression in a trigger is being fired whenever a new song starts, or when the master deck changes during play. In this expression, the midi note gets fired to activate the correct Ableton tracks. I'm pretty sure it must be possible to fire some sort of other command to Ableton so it knows what the correct position is of the new track, but I need your help in telling me what kind of command you need for this. Is it a midi note? An OSC command?
In that case all we need to know is when a Master Track Starts, from what position, and in what speed.
Simple 3 OSC messages like they are now : /enable $1, /speed $1 and /time $1
The problem You had with SMPTE-2.amxd is that BLT is sending more infos than that.
Probably decks are sending enable 0 messages when they stop, ignoring the
fact that they are not master Track.
If You can organise a trigger that sends only infos from current Master track,
I would will be happy as a pig in the mud.
You could name it /master/enable master/speed and /master/time
And that infos should be sent whenever a Master Song starts,stops, resumes or restarts loop.
So to say on any state change.
Just had a look at
https://github.com/brunchboy/beat-link-trigger/tree/master/doc#watch-menu
It clearly states :
Master Player
If you choose to watch the Master Player, the trigger will focus on whichever player is the current Tempo (sync) Master.
So that should be easy thing to do.
I'll be happy to compile new max4live plug to use new OSC messages.
Just confirm that /master/enable master/speed and /master/time adresses.
And to repeat again - whenever Track starts or restarts after pause
You must send new position in ms immediately after /master/enable 1.
If Loop turnover also sends enable 1 message, then You must also send
time position.
that is so because Live has no working resume from last position command.
Yes, I'll put those 3 OSC message in the activation expression. Can you provide an app that listens to those messages?
Sure, I'll send it in few minutes.
Wow, this is a huge thread, which I’ve just been pointed at. I am hoping to find some time to help this weekend, but wanted to say a couple of things first. Thanks everyone for putting in so much effort in trying to get things working! In response to an earlier comment about my SMPTE standalone being inefficient, I have no doubt about that—I know next to nothing about building Max applications, and built that only as a proof-of-concept to show that it would be possible to generate SMPTE timecode with the help of BLT triggers. The idea was always that another group of developers were going to write a C program that would do it much more compactly using libltc. But they never had time to finish it.
Secondly, Source Audio—you’ve done some amazing work putting together better solutions for this stuff, I am really impressed! At one point you asked for more information about the messages sent between CDJs, such as whether they provide the timecode and so on. They provide a very strange and difficult-to-use set of information, and I had to go to incredible lengths to turn that into vaguely accurate timecode. You can see all the details that we have been able to learn about their UDP protocol in an article I wrote to share those discoveries here.
I think a big part of what is making this so difficult is the fact that the lighting control tracks in Ableton are not encoded at the same BPM as the tracks they are supposed to work with. That causes us to have to defeat and work around many of the mechanisms we built to try to perform sync. Is there any way to re-encode those so that the lighting cues appear at the same beats (and times) as they do in the actual tracks?
Well in my setup, the global BPM in Ableton is set to 120. The audiotracks in Ableton are warped. If I set the pitch on the CD players to +3%, the BPM in Ableton should change to 120 + 3% = 123.6
If that is implemented the midi track stays in sync.
Hi James and thanks for joining in.
And please don't take my bla,bla about standalone building too seriously.
And by the way if any need for help in whatever direction arrises, I'll be glad to contribute.
You see all this became a bit longish dialog, mainly because Johnny and me took a bit time to understand each other, ha,ha.
I just joined in to provide some help with getting MTC or whatever kind of sync work.
I don't use any CD Player, and also no Live.
My thouth simply was to go as directly as possible from Beat Link trigger to Ableton.
Having that phasor~ in between is not necessary.
Only if SMPTE has to be generated from standalone.
If Johnny created tracks in Live using real BPM, that would habe made things easier,
in terms of using carabiner, or midi beat clock.
But I am sure it is going to work also like this, kind of real time as well.
As long as the lighting tracks are not warped, and are at a fixed 120 bpm, you should be able to make use of the feature that I added to BLT for you which locks normal playback sync speed to 120 bpm (or whatever value you set) regardless of the actual track BPM. That is described in the section “Ignoring Track BPM” in the user guide.
You need to be sure you are using the latest 0.3.8 preview build for that feature to exist, however.
And hello Source Audio! No worries, I understood what you were saying and have no hurt feelings about my Max example! I’m amazed it worked at all.
With all of us working together the best approach may be to define exactly what events and messages you want BLT to send for your code to control Live, then I can write the Clojure code to do that.
Right now I need to focus on my job that pays the bills: we are doing some very challenging design work there. But this weekend I will reread this thread and try to figure out exactly what is missing for things to work. It’s confusing because there have been so many variations, and the precise details matter.
So for the past 2 hours, I've been trying to send the correct OSC commands at the right times, but it's proving much harder than I hoped.
I had managed to get the BLT-Live device working, where the /master/enable, /master/speed and /master/time were getting sent, but whenever I did a started a new song before the first song had reached its end, the transport in Ableton would stop the moment the first song had reached the end.
Pausing the newly started song and resuming it, also resumed the Ableton transport.
I'm afraid I reached the limits of my programming skills here...
This is what I came up with so far:
(timbre/info "ACTIV: FLAG 1")
(let [client (osc/osc-client "localhost" 17001)
handler (reify org.deepsymmetry.beatlink.data.TrackPositionListener
(movementChanged [this update]
(timbre/info "ACTIV: FLAG 2")
(overtone.osc/osc-send client "/master/enable" (int 1))
(timbre/info "OSC: /master/enable " (int 1))
(overtone.osc/osc-send client "/master/time" (int (.milliseconds update)))
(timbre/info "OSC: /master/time " (int (.milliseconds update)))
(overtone.osc/osc-send client "/master/speed" (float (.pitch update)))
(timbre/info "OSC: /master/speed" (float (.pitch update)))
))]
(swap! locals assoc :smpted client
:handler handler))
Is it working other than that? If so, we should perhaps focus on just getting the events right. Can you send me your entire trigger file? That would be much easier to study than trying to figure out what all the expressions are doing by description. And is there documentation of all the OSC commands that the BLT-Live device accepts, and how it works?
Here is a simple schema of OSC messages expected in BLT-Live.amxd
/master/enable 0 or 1 to start playback
/master/speed nn (value in float it is used to multipy BPM in Live Transport)
/master/time nn ( position of master deck playback in miliseconds)
-------
So it actually just reacts to same messages as SMPTE.app
Live timeline is expressed in ticks, and Live treats 1 quarter note
as 1 tick, regardless of time signature.
For that reason I have to calculate Live start position
form received position in ms and speed from ther BLT.
For example in tempo 120 1 quarter note, or 1 tick
is 60000. / 120 = 500 ms
If BLT sends /master/time 15333 the I have to
15333. / 500. = 30.666 ticks
message to live is : set current_song_time 30.666
If BLT sends /master/speed 1.03 then 500 ms becomes 485.4368932
and new position is 15333 / 485.4368932 = 31.58598 ticks
--------------
Main trouble I have here is actually the fact that Live does not respect
new set position if it is stoped.
Even if one does it manually in the Transport, Live will allways resume
playback from the last position where it stoped, what a shame.
That makes it necessary to sent time message whenever
CD Players start, resume or loop.
There are other anomalies in the way Live Transport behaves,
but let's leave that for now
Next thing is speed - I sent yesterday 2 versions of BLT-Live
and the only difference is that in first version, received
speed and time messages allways retrigger new play position,
whenever one of the messages comes in.
In second version new position gets triggered only when time
message gets received.
This would be the needed order of messages :
/master/enable 1 /master/speed 1. /master/time 0 to start Song from beginning
/master/enable 1 /master/speed 1. /master/time 1000 to start, resume,
loop from 1000 ms
/master/enable 0 /master/time 0 to stop and rewind Song
Resending of speed messages would not be needed if it did not change
And Johnny, please don't loose Your time reprogramming 100 Songs
before it all gets sorted out, and best approach is found.
By the way , did You remove all other m4Live devices which listen to BLT
from Live ?
Like SMPTE.amxd etc
If not, that would explain why Live stops, because they all listen
to /enable messages from individual decks
Hi James & Source Audio (is that your real name? :) ),
So I experimented with trying to send the correct OSC messages to Ableton, and at some point it kind of worked. The transport was running, and when I changed the pitch on my CD player, it also changed in the AMXD app.
However, the transport stops when I start a new song B during the fadeout of song A and song A reaches its end. I'm pretty sure this is because my shutdown expression in the trigger sends a "/master/enable 0" message.
But when I pause that new track (song B), and resume, the transport is back on track and in sync.
So, with my limited knowledge, I would reckon that the app is working fairly well, but the main problem is indeed getting the events right.
My entire trigger file is attached to this post
The first trigger is the one that sends midi notes to Ableton that are mapped to activation/deactivation buttons of tracks. The trigger looks in the Global Setup Expression for a match based on artist-name, track-title and album-title, and if so, the respective midi note is sent through the midi channel which is also included.
This trigger works pretty well right now, however I'm pretty sure that code-wise it could be improved quite a bit.
The second trigger is the one that should send the 3 osc messages to the AMXD app in Ableton, and needs assistance. I'm not completely sure what expressions in the trigger need to contain what code in order for it to work.
----
Besides these 2 triggers, another 2 will be added to get the dual SMPTE stream running to Resolume.
James, for this I've used your SMPTE-Left and SMPTE-Right triggers that are in your user guide, in combination with the dual SMPTE daemon, and it works fairly well.
In these 2 triggers I am planning on querying for tracks in the Global Setup Expression and send the same midi notes to Resolume to trigger the correct videoclips on the correct layer.
----
Thank you very, VERY much for both of your help to get this up & running. I feel we are REALLY close in getting it all to work!
PS: This forum wouldn't allow me to attach a .BLT file, so I added .TXT to the file extension. I think you need to remove this again after download to get it to work.
No, that is not my real name, I prefer to stay anonymous in any forums
just be able to pull out if it starts spamming, advertising etc
because that did happen quite a few times in the past.
Also mail adress is not my personal or business, so I can delete it anytime.
Back to the thema -
I had a look in the text of the trigger You just posted.
Not that I fully understand the syntax of BLT triggers, but I found only one instance
of /master in the whole text, : \"/master/enable\" (int 0))"
and it is in the code for left deck as far as I can see.
So this can't work.
--------------------------------
I have created for myself Max Patch that emulates 2 CDPlayers,
and sends OSC messages to Live.
Each player sends own values /left/enable etc for left deck
and /right/enable etc for right deck, independent of master status or time.
Deck that started first is Master deck and it sends /master/enable etc values.
When second deck starts, it opens gate which listens to "Song ended" message
from first deck, and uses that message to become new Master.
So it sends /right/enable 1 , /right/speed 1 and /right/time 0
at point when it started in background. That should be used to run the SMPTE for that deck.
But it sends master/enable 1, /master/speed 1 and /master/time 2000
only at the moment when it became master deck. In this case 2000 ms elapsed
from the start of deck 2 till deck 1 came to the end, or end of fadeout.
That way the first deck does not send /master/enable 0 message to Live,
Live actually does not stop , it just gets new speed and position.
Everything works just fine like this.
--------------------------
There is another thing I wanted to point :
If DMX data in Your Live tracks is triggered type, like note number
or program change, You might get problems when using Play offset
as latency compensation.
Because Play position would never really hit the 0 Time
of a Song, or THE beginning of a Loop,
and if event was placed there it will just not get played.
Only Continuous controllers get chased in a DAW with such option set.
I don't know how Live is dealing with it.
Hi Source Audio,
Both of the triggers listen to the Master deck, so this does work when the trigger itself is programmed correct.
But thinking of it, I wonder if it is even necessary to send a "/master/enable 1" on start and "/master/enable 0" on stop, because I would expect the master deck to be always "on"?
Your solution for the left and right could work in my setup, I'd be happy to test it, but i'll need some assistance to get this trigger to work sending the correct OSC messages, since I can't seem to figure out myself the correct Clojure code, and I'm very much struggling to find the correct expression to post it in.
About my DMX setup:
I programmed my midi tracks that contain the light-cue's in such a way, that they hold up with a bit of latency. For instance if one cue in a part of a song is active for 10 seconds, then it's not just 1 long midi note that is being played, but the whole 10 second bar is chopped up in very small notes, so if the transport would jitter and jump over the very beginning of the first note, it would still get triggered wherever it lands within that 10 second bar. It works great.
I use the DMXis plugin in Ableton which connects to a USB-to-DMX box. You can check it out here: https://www.youtube.com/watch?v=x5oiPA6b-bY
I think if James could help a bit with the configuration of the triggers, to send the correct messages at the right time, so the transport keeps running whenever the master deck switches, I believe we are pretty much getting to the result I am hoping for.
I think it is a safe bet to allways send values to live, otherwise it will not know what to do.
You can set a Player at some position other than 0, but start it at some later point.
In that case, and if it were the Master deck, it should send /master/enable 0
---------
But if I understood right, this /left and /right triggers are allready done, is that true?
If so, I could try to programm the logic of switching between decks in Max4Live.
Ideally, You would allways send status of both decks out.
Then I could make max4Live device that would listen to that, and generate 2 SMPTE
streams, which would not have to do anything with Live Transport.
And each deck will run it's own SMPTE.
Then I could try to setup a logic, which monitors what the decks are doing,
and create a sync for Live, depending which deck was set to play last.
For that to work, the decks should allways send 3 values out.
When they start - enable 1, when they stop or pause - enable 0.
I guess that deck sends enable 0 message when it plays to the end, when it finishes fade out
or when it goes into pause.
That could work, would cost me a bit of time,
but it could save You a lot of time needed to make new triggers.
And all would be packed in a single m4l device
I would very much like to keep the whole Ableton+Lights trigger(s) completely separate from the 2 SMPTE triggers, for the simple reason that I won't be using the SMPTE at all my shows (not all my shows are with video, but they are always with the DMX). And really, I'd like to keep the Ableton and SMPTE/Resolume devices separate as well.
I also feel that splitting up the 2 decks in separate triggers to ultimately end up with 1 stream of sync to Ableton is the wrong approach. I'd very much prefer to have 1 trigger for Ableton that listens within BLT to the Master deck, and with a correctly programmed trigger handle the OSC sending at the right times. BLT already has the technology built in to decide which deck is Master, so I think we need to build on that, instead of writing our own code to figure out the Master, when it's already built in BLT.
By the way, there will sometimes be situations where I have a 3 or 4 CD-deck setup (some clubs or festivals have set it up that way). Therefor, for the Ableton sync, it is crucial that the trigger used to connect to your device listens to the Master deck (there is always just 1 Master deck, not 2. Well sometimes it's 0, but that's not important I think).
I really do believe that getting the sync working in 1 trigger is possible, for the simple reason that we're just about there already. Right now I think, if we can figure out how to prevent the transport from stopping between songs, we're pretty much done. I think pretty much all it takes is a solid coded trigger that does just this, and I hope that James can have a look at it, because I even think it isn't a very complex trigger that needs to be written to get the job done...
That makes it clear.
So let's see how it goes.
By the way could You test the pure MTC.app version ?
That’s great, guys! I need to cook brunch and do a couple other things, but will look at these files and thoughts in depth this afternoon, and see if I can come up with a way to make the triggers send events that work the way you need, in a clean and understandable way. I should be able to confirm basic operation with my own setup, but then you will need to test for proper sync with your actual tracks once I send them back.
By the way, what is the deadline for this?
In the meantime, I adapted James’ trigger for the single SMPTE to send the new OSC commands, and it works really well (the transport keeps running when switching decks), and the sync is prettty accurate, but some others problems showed up:
- the transport seems to never stop
- while testing, after about 10minutes, BLT started acting weird. The decks in the Player Status window kept playing, even when I had paused the tracks. Also, the trigger that sends the midi notes stopped working altogether. Is that a bug? I’m using BLT version 0.3.8-PREVIEW, on a Macbook Pro.
- after some time, the sync starts to drift away a bit. Is it possible to incorporate a continuous check so the sync stays good?
Source audio: If you meant by the MTC.app the last app you uploaded, than yes, thats where I’m currently testing in.
James,
I don’t want to impose a deadline on anyone, and definitely not on the both of you.
I have a big show coming up on April 30th, for which I’d love to use this setup, so if we could finish this a couple days beforehand so I can test a lot, that would make me insanely happy!
By the way, would it help if I sent you my ableton file and a couple audio tracks so you can test it yourself?
I’ve been able to download the trigger file (uploading it with a .txt extension, as you suspected, was a good workaround), so I should be able to do initial testing. If it turns out we are getting close enough that having me test with your actual tracks and Ableton files is helpful, then I’ll let you know and we can figure out a private way to do it, thanks! We can hold off on that for the moment, though.
Would you rather have me start with the file you already sent, or the one you are working with now, where you modified my SMPTE triggers to send the OSC commands needed by MTC.app?
The problems you are describing sound like you have some code in your triggers which is crashing and preventing BLT from reacting properly to the events being sent by the players. You can check for that kind of thing by looking in the logs; you will see exceptions reported and stack traces. So “is it a bug?”—yes, probably, and most likely one in your triggers. Anything you write in the triggers is run at the same level as the rest of the code in Beat Link Trigger, so it can definitely introduce problems. But we should be able to sort it out. Feel free to send me that version of your triggers file if you would rather have me look at the logs, or quote a bit of the logs here.
As far as drifting out of sync, I believe Source Audio mentioned something about this a while back: the SMPTE-style sync code is not an ongoing sync, it simply tells Ableton when there are tempo changes, or unexpected changes in track position. So since the players and Ableton are generating independent clock signals, they can definitely drift out of sync over time. We could fix that by periodically sending a position instruction even if we aren’t responding to an unexpected jump. (Anything is possible, because we have access to the full programming language and environment used to implement the underlying software.)
Thanks for letting me know about the 30th date; that reassures me that even if we only make partial progress this weekend (because I do have to do some additional work for my employer, and am going to a show tonight, and celebrating a birthday tomorrow evening) we have time to sort out the remainder in time for you to test and convince yourself everything is working the way you want for your shows.
Hi James,
As it stands right now, I think our best way to go is to keep the trigger which sends the midi notes to Ableton to activate the tracks. So far that works, but perhaps you could look at that code as well. I'm sure the code i've compiled from bits and pieces here and there isn't rock solid...
Besides that, I think building on your single SMPTE trigger, and adapting it to send the corrects OSC messages, is the better way to go. However it needs some tweaking as i've mentioned in my previous post. I think the tricky part is in getting the trigger to NOT send a "/master/enable 0" whenever a song is still playing. "/master/enable 0" should only be sent when ALL music has stopped.
If possible, sending a periodical position instruction would be really helpful I think. Not only have I experienced to see the sync drift off with longer songs, also I've experienced some latency when switching songs on different decks, which the position instruction hopefully could fix and get the sync back on track.
I'll check the logs the next time I am experiencing the same problem again with the player window, and will let you know.
All right! I think I have caught up on the recent messages, and want to make sure I am working on the right thing. Here is the plan as I understand it:
We want to start with the Trigger file that Johnny already uploaded for me, and use its trigger that sends MIDI notes to Ableton to activate tracks. I will review that code and see if I can suggest improvements.
Also, I will create a new trigger that watches the Master player and sends OSC commands to Source Audio’s BLT-LIVE.AMXD to control transport. (Is the version that was uploaded here on April 13 2018 at 10:50 AM CDT the correct one for me to download and experiment with?) My new trigger should:
Enable whenever there is a playing Master player
Only disable when there is no longer any playing Master player
Send position/speed updates based on inferred timecode from that player, and
Send periodic position updates to avoid drift, at a configurable interval
Does that sound good? And is the following the correct set of messages that I need to work with?
/master/enable 0 or 1 to stop or start playback
/master/speed n.n (value in float it is used to multipy BPM in Live Transport)
/master/time nn ( position of master deck playback in miliseconds)
So to go at 110% speed, the /master/speed value would be 1.1? And from what I understood elsewhere, sending time values does not work properly if the transport is not enabled?
Then, later on, this can be combined with my existing SMPTE triggers for Resolume, but keep in mind my SMPTE daemon is only a proof of concept, not anything rugged, so be sure to test thoroughly before counting on it in a performance setting. And unfortunately, if it does not work, I cannot update or improve it, and the people who were supposedly working on a real implementation seem to have given up.
Also, while I am raising cautions, keep in mind that if you have four CDJs at a festival, getting metadata from them is difficult (and is required for timecode simulation), so you should save a metadata archive of your media stick, and mount that within BLT.
Oh! I just saw Source Audio’s more explicit schema of messages to send BLT-Live.AMXD, which is very clear and helpful. I will work with that, and have updated my message above. I assume that a speed of 1.0 always goes back to the default BPM, correct? I would be very interested in how this code was implemented, is there documentation of how to control Live this way?
It’s unfortunate you have to go through such gymnastics to translate times to song positions based on the tempo changes. It sounds like some of the craziness I had to do in the first place to get time information out of the CDJs. One more question, though, can I jump to a time by just sending /master/time if the transport is already playing, or do I always need to also send the /master/enable 1 first?
Hi James,
I'm not sure if it would make more sense to combine the trigger that sends the midi notes to activate the Ableton tracks, and the trigger which sends the OSC messages (also to Ableton) into 1 trigger? I'll go with whatever you think is best.
The 4 bullet points you summed up are all correct. I'm especially worried about keeping the tracks in good sync whenever I go from one song to the next. I hope the periodic position updates will fix that.
The OSC messages also look correct, and indeed 110% speed would be 1.1
Since I won't be using SMPTE all the time, only on bigger festivals, perhaps it's better to keep the whole SMPTE aspect in separate triggers? I have implemented your 2 SMPTE triggers for left and right deck in the past, and they worked great. Not sure though if they need to be updated as well in this current setup?
I was aware that 4 decks might be a problem for BLT, which I will keep in mind to unplug 1 deck whenever I arrive at a show where 4 decks are present. But actually, since I have 3 decks on my technical rider that goes to show promotors, more often than not, there are 3 decks present.