transport
I hope this isn't a dumb question, but it looks like I should be able to sync a transport object to a DAW beat clock, right? In other words, I want the DAW to control my transport tempo in Max. I see an attribute called @clocksource. Does this mean, for example, that if I use the attribute "@clocksource Live" it will sync to the tempo of Live? If so, why isn't it working? Am I not understanding what the @clocksource attribute is, or am I missing information about how to use it?
BTW, I know it's not syncing to Live's tempo because looking at what comes out of transport's "tempo" outlet shows this.
are you trying to sync Max application to Live's beat clock ?
I would use real midi beat clock and SPP
instead of trying to get transport to extract tempo
from incoming clock.
For several reasons.
Thanks for your reply!
Sorry, but I guess that I'm more of a novice than I thought. I don't know what you mean by SPP or "real midi beat clock". I thought DAWs have a midi beat clock output.
I have synced Max to both Live and Studio One using Max's rtin. But because I'm having a problem doing exactly what I want to do via that method, I'm trying to see if there is a way to sync a DAW to Max via a Max transport (on the outside chance that will give me different options for trying to solve my other problem of accomplishing what I want to do in Max).
transport can not sync to other DAW because there is no connection between them
other than trying to detect tempo using again midi beat clock,
which uses rtin object in max.
SPP Song Position Pointer is needed to follow DAW's position
if you don't only run it from the beginning.
otherwise there are some chances that you get what you want
(and I have no idea that that is) trying rewire~, hostsync~, hostcontrol~ etc
Thanks, I'll look into those other objects...
I must be misunderstanding what the attribute "@clocksource" means, because it looks like it must make transport sync with an external beat clock. I couldn't find anywhere in Max's documentation where that attribute is fully explained. When I send the message "getclocksources" to transport, though, it does output the message "append live". So it is actually "seeing" live out there somewhere. To me this is all very mysterious.
What I want to do is generate different tempos that are all related to, and synced with, an incoming beat clock. I actually made a patch that accomplishes this in a roundabout way, but because of the way I did it the resulting tempo pulses aren't always even. Just in case you are curious, I'll attach a picture of the patch I was experimenting with...
The important part is that I load each of the seq objects with a different midi file containing a string of different note value, then force the seq objects to repeat their patterns by banging the start message (because seq can't loop on its own). The problem is that there's a time glitch each time seq is restarted. For that reason I'm looking for other ways to make related tempos. I thought it looked like maybe I could use the transport to do that, but alas.
I've also noticed that [seq] has some unpredictable latency of the start message. So it's not useful for smooth looping. Alternatively, [detonate] should work much better (with tempo control by adjusting the delta times).
the resulting tempo pulses aren't always even
+1 for 'rtin', i've used it to sync to other apps in combination with the 'sync~' object(might not be as CPU efficient, but you can then split off related-to-tempo by rate~ objects from there... just mentioning if you find event-based sequencing is still not accurate enough... i also prefer 'detonate'(i wonder if 'mtr' will take the place of 'seq' for most people now, too) so to make it easier to change delta-times, you could also grab the BPM info. from rtin/sync~ and inform a separate 'transport' object, then you can still have access to metrical-based timing options for 'translate'(can translate from metrical timing to 'ms' for you) or send metrical-timing-based messages straight into any 'pipe'/'del' objects you'd use needing tempo-related delta-times).
hope that makes sense and helps 🍻
Thanks BROC and Raja for your suggestions. Since I'm pretty new to all this it might take a little time for me to get it right, but it looks like you've pointed me in the right direction! I'll give it a try...
Raja, when you say "grab the BPM info. from rtin/sync~ and inform a separate 'transport' object", I'm intrigued. If I understand what your saying, you can control a transport's tempo via sync~'s BMP output. This might be an ideal solution, but I see no way of getting transport to follow sync~'s BPM info.
BTW, I did run a rtin/sync~ setup into a rate~ and play with multiples of the tempo. It all looks great on a scope, but when I take the output of rate~ and put it back into another sync~ so I can use BPM info to make bangs, what comes out are horribly uneven bangs (the pulse is not steady). I suspect that the output of rate~ is not meant to be fed into a sync~, right? Either that, or the BPM info coming out of sync~ isn't meant to trigger bangs. So maybe my question should be, how can I turn the ramp coming out of rate~ into a series of bangs that I can then use to run some other patches I've made? (Assuming, of course, that rate~ actually can give me a steady pulse.)
You are mixing apples and oranges.
From the screenshot one can see that you don't use different tempos,
but note divisions, running at SAME TEMPO.
That said, another mistake is to connect rtin directly to seq
which would then bang on any message and not only 248 - tick.
Sync like that makes also no sense (at least to me) because there is no elapsed time
information from host - Song Position Pointer.
And another thing - mixing signal and non signal objects in sync
chain easily results in unsteady things, and is also depending on DSP Settings.
----
Back to your project - that is a trivial task, midi sequencers did that
many years ago - play independent midi tracks synced to external beat clock.
So what are you trying to reinvent ?
I can imagine that that midi files are not really complex, or ?
Otherwise effect of polyrhytmic would not be pronounced
but end in mass of bussy notes.
From the screenshot one can see that midi notes are not used as notes at all, but as division triggers ?
Is that it ? Why bother with all that ?
The only sync to host seems to be tick pulse.
From that one you can generate whatever you want if it is not realtime related,
which seems not to be the case.
There were many treads here on the forum dealing with different beat divisions,
or bar related free divisions, synced or not, using signal objects or not etc, etc.
But it is still not clear from your post what exactly is your goal,
and so remains difficult to offer a solution from really numerous ways to pulse arround.
------
If it is as simple as to create different pulses which have some kind of length related to
beat clock, and you seem to want to use midi related note length values ( or ? )
then there are so many simple options...
but midi beat clock has it's limitations when it comes to for example dividing a Bar into 37 beats ...
Do you need real time related sync ?
Means if you start host DAW at bar 44 beat 2, should all pulses
you want to execute in Max patch do exactly what they would do if host started from beginning ?
Or all you need is a common start, and then follow pulse ?
Yes, Source Audio, I think what I want to do is simple (in musical terms), but I can't find a simple solution for it in Max. I just want to generate multiples (or divisions) of an incoming beat clock pulse. The only reason I used MIDI files with seq was because that's the only way I could figure out how to do that. I would prefer that Max would allow me to control the transport pulse via midi beat clock. I currently don't expect that I will need to have all this relate to specific beats or bars in a DAW project, at least not how I'm currently envisioning how I'll use it. I'm not going to be making dance beats or anything like that and I'm not planning on using this ability for a traditional song.
It's beginning to look like what I want to do may not be possible... (?)
BTW, I had followed the method used in some examples I found that were supposed to take care of the clicks before connecting up to seq (sorry but by now I've forgotten how I did it), but it didn't seem to do what it was supposed to do and I discovered my patch worked the same without it. Maybe I'll have to go back and try to find those examples again...
Thanks for your reply.
then ticks will rule your output.
You can use them to count and group them to create bangs,
or to try to extract tempo and then run other stuff by that.
sync~ or timer would work similar, but timer would need no signal
here a bit of comparison :
sync resolves bpm to only 1 decimal place
or here a bit more chaos
i don't want to confuse, you can just follow SourceAudio's advice(the last couple patches he posted shows what i meant anyways). but to clear up some of the more basic confusion:
take the output of rate~ and put it back into another sync~
i only meant rate~ for ease of using signal-accuracy, depending on what you set each rate~ to, you would know the mathematical coefficient for subdivision(you don't send rate~ to sync~... sync~ is like a master phasor~, rate~ is used for rhythmic augmentation/diminution of phasor-style ramps).
i'd recommend though: eventually, it would also be worthwhile for you to look through the Examples folder of "sequencing-looping" for more understanding on how to divide out subdivisions from a master clock and control things rhythmically in different ways.
(also, just to answer: converting signal ramps to bangs is explained in the phasor~ helpfile under the 'tempo-relative' tab...)
And --- tempo object is another example of sluggish update of help, reference etc files
Tempo can actually divide whole note into 960 divisions and NOT 96 as stated.
means smallest interval is 2 ticks
Beat multiplier seems to have no limit.
Thanks for the help and the patches, you guys. I had actually been trying to do a couple of the things you show me in the patches, like counting ticks and using edge~, but things didn't seem to be working out for me. The part of your patch (with added noteout) that I'm including as a screenshot is basically doing what I want to do, but it's not steady and stable. I'm including an audio file of what I show in the screen shot in action. You can hear extra bangs being thrown in. I've been having similar problems with instability in my patches.
the delta~ object takes difference between current sample and previous. so to find the beginning of a new ramp, you want a negative number(at the start of a new ramp, the difference is 0(current-sample & 'start') - 1(previous-sample & 'end') = -1; using 'greater-than-zero' will probably trigger everything too much, since every part of the ramp, through delta~, except for where it resets to start, is true for the 'greater-than-zero' op),
so just change the ">~ 0." to a "<~ 0." and it should give you the desired response.
... unfortunately changing from ">~0." to "<~0." didn't clear up the problem.
I suspect it's a problem in which sync~ (and/or rate~) get out of sync with the incoming beat clock and then need to occasionally recalibrate (as if the timing of the two aren't exact enough so they start going out of phase). I say this because if, while the patch is running, I disengage the beat clock by switching rtin's input to "none", then it continues beating without any hiccups. However, if I reengage the incoming midi beat clock, after sync~ recalibrates to the incoming pulse, the problem will eventually return.
Not really understanding what's going on "under the hood", I could be way off base here, but...
oh, also, i don't think "@sync lock" will work well in this case(try it without that, i think that'll improve it more.. but then you probably want that type of behavior... it's been known to have probs when attempting to lock to a phasor which is synced by some external mechanism(sync~ probably works like this and has troubles as you say))... so i guess the prob is that you actually want to split divisions of a clock which is external to max(otherwise, if you used phasor~, rate~ would work with sync-lock better), this is because for software to talk to software, there'll always be at least some delay(which is generally bad when trying to sync clocks). ya, apologies, i'm not sure what else...
I sent rate~ the "sync lock", "sync off" and "sync cycle" messages, but they have no effect.
So it doesn't seem possible to do exactly what I was hoping to do without having some glitches. Alas...
Anyway, thanks for your time and help, guys!
problem for sure is sync~ object.
I would avoid using it at all, but if you still want to use it
make sure to turn overdrive on, Scheduler in Overdrive on, Audio Interrupt On
The test part you posted with sync~ and rate~ performs here decently, without
"extra" triggers, but it takes time when tempo changes to readjust.
That makes it unusable if host needs to change tempo on the fly .
If rate~ objects are not synced then they would not start together...
And if host for example stopped at bpm 111, and then you start it with 122
sync~ will start using old tempo, then eventially adjust to new received tempo.
IN SIMPLE WORDS - USELESS.
Better than that sync is no sync at all - just send start and stop using midi and set same tempo, and this will run in sync, even on different computers.
And long enough before driffing out of sync.
Of course only if tempo does not need to change.
-----------
If you need to change tempo on the fly I see only one rock solid option :
use midi beat clock to run counter and divide note lengths from that.
it does not need to recalculate phase to incoming clock.
At the end it is a matter of calculating relation of bangs timing to original pulse,
which might look a bit more complicated when dealing with ticks.
You want to use bpm, ok :
Midi beat clock gets sent 24 times per quarter note.
quarter note is 480 ticks long, means 1 midi beat clock is 20 ticks long.
If you use counter to progress beat clocks and divide them to arbitrary note
lengths, then just consider that relation.
Like rate of 0.75 to 1 quarter note would be for tempo object
3 16th notes, or for counted beat clocks 18 (24 / 4 * 3)
Only problem is that counted clock divisions are then limited to 1 beat clock or 20 ticks.
if your notes divisions can live with that, there is no better solution.
If you need more flexible divisions then detect tempo using timer
on rtin clock input to drive transport and use raw ticks output of
transport to divide pulse lengths.
That adjusts to tempo changes faster than sync~ object
and would then be more flexible than counting clocks,
but needs tempo detection.
Thanks, Source Audio, I think the right side of this patch will be helpful for me! I had tried counting ticks before I started this thread, but wasn't doing it properly. The % object seems to be really handy...
I'm not so sure the left side of the patch (with the transport) is working for me (I had to add a toggle to the left input to make the toggle start.) But like I said, I think I'll be able to use what you're doing on the right side of the patch.
Thanks for the help!
Just to let you know, Source Audio, I came back and looked at your patch again today and realized that the reason the left side of the patch didn't seem to work was because I wasn't turning the DAW's beat clock off and on. I had it running when I opened your patch and just left it running while observing it, so your patch never got the start message from the MIDI beat clock. But you probably figured that already anyway. Sorry I missed that part. I am pretty new to this, but hopefully catching on fast...
Well, I could not get that.
I thought that transport did not work for you simply because you disliked it.
One would think it was obvious that on needs to send start - stop,
but as you say it is easy to overlook that some things needs to be stated clearly.
Also counter version needs stop in order to reset to beginning.
If you also want to implement Song Position Pointer, it should not be too difficult to do...
... I'm sure that I'll eventually get around to needing Song Position Pointer at some point, too.
Thanks, again!
take a look here
Wow... this is great...
It's going to be very helpful. I've learned a couple things from it already.
Thank you very much!
Hey @PSG, did you find a way around your problem? I noticed it is impossible to sync when I have audio interrupt set to on. After turning it off, I managed to get it working with Studio One.
I am recording MIDI from Max in S1, and I have the clock controlled by s1's transport through another port (to Max 2). Then, in order to have proper control from s1, I send only MIDI clock, not MIDI start nor timecode from S1. SPP is ignored, external sync in S1 is off. Otherwise start/stop doesn't work properly for me. I also have precount on and no preroll on s1, and I record MIDI to arrive with a -15ms Record Offset, now everything works like a (duh) clock.
Hello, Felipe.
Like you, I only used a beat clock coming out of Studio 1. At one point I actually contacted Presonus to find out why I couldn’t find SPP anywhere and somebody wrote back and said something like “It seems that Studio One does not support SPP”. I don’t know if that’s because I’m only using the “Artist” version, or if not even the “Professional” version has SPP.
What I ended up doing for that project was to use only MIDI data generated from within Max so the exact timing of how things synced to S1 actually wasn’t an issue. I wrote a Max patch that played many different voices (or layers) all at the same time based on the pulse coming out of S1, so all the MIDI data going back to S1 was already in sync with itself. I basically used S1 as a MIDI data recording device and let Max take care of all matters of timing based on S1's pulse. The patch could play the entire piece in one take (with me inputting pitches via midi keyboard and turning some voices on and off along the way). So in the end, I probably could have done what I did by having Max create its own tempo, but since I had already set things up to run off an incoming beat clock I just went with that.
In the future I will probably still want to sync parts on a DAW (be it S1 or not) with what a Max patch plays, so what you say here will be helpful.
Thanks for your comments... and I'm glad you got things to work out!