Ableton Forum

hello abletons,

the 2.02 update solves some timeinfo issues which is very
nice , thanks!
..but...
theres still some things missing..

could you please also implement the
'transportCycleActive' flag and
'cylceStartPos' and 'cycleEndPos'
?
that would make me very happy!


thanks, regards
°/andreas

Can you tell me which VST Plugin uses this information and for what? I need something to test with for an implementation.

Frank

hello

there is tobybears host-monitor KONDOR plugin (pc only) that
shows the hosts canDo's and all that..
http://www.tobybear.de/

sorry, i dont know which plugin actually uses it..
except the one im currently developing..
(its a step-sequenced vst sampler.
-> for sample-accurate sync , i need this info from
live (to know the internal sequencer position of the NEXT step..))

the values for cycleStartPos and EndPos should be in PPQ ..
(thats the way cubase does it)

thanks alot ! regards
°/andreas

For what do you really need this feature in your plugin?

Anyway, there is a problem. Since in Live tracks can have clips playing in Session or in the Arranger. A Loop is only available in the Arranger. When a Clip is started in the Session it would not be in a Loop, right? We can set the Timeinfo according to the fact if the clip is fired in Session or Arranger. But which solution should there be for effects on sends? Sends can feeded by clips playing in Arranger and Session at the same time. What would you expect there?

Another interesting aspect is, that Live doesn't support VST instruments. When you implement an effect as an instrument, you misuse the standard. What for example happens to the audio played on this track?

There is still the option to do something like this with Rewire and use Live as mixer application. This solution would have its very own limitations though.

Frank

hello frank,

i need this feature for the following:

when live is playing in cycle / loop modus, there obviously is
a playback-position (ppqPos) jump happening when it wraps
at cycleEndPos...

now the stepsequencer in my plugin (which is synced via
samplePos and ppqPos) needs to know that such a jump
will happen , to also wrap the playback position of the
step-sequencer correctly..

its not such a big issue, still would be nice to have that info..

and what happens to audio on that track:
my plugin can fill its samplebuffers by recording from audio
input... (or by loading files)
it 's kind of both an instrument and effect..

i dont quite understand the problem you describe, about
session / arranger ..
i dont see how this affects this whole issue. live is playing
either in cycle mode or not,... or do i oversee something here?
also i dont understand why this timeinfo would have to
depend on where a clip is playing, since clips dont affect the
main timeinfo / cycleSettings anyway..

thanks for your answer
°/andreas

A clip started in the session doesn't take care of the clip in the Arranger. Try to make a 4 bar song loop in the arranger with one clip and fire a 5 bar clip in the session. You will realize that you get several permutations. A clip started in the session has no loop in Arranger terms.

The question is: shall we support the loop feature, which is simply wrong for clips fired in Session? What do you think?

Frank

_________________
[email protected]
http://www.ableton.com

not quite sure if we talk about the same thing...
what i mean is very simple:
report if the MAIN cycle modus is on or off, and
report the current cylce-settings...
NOT of any clips, the main TRANSPORT cylce !
i dont see what this has to do with clips?

it doesnt matter how clips behave in cycle mode,
its just about reporting what the user has set on the transport
thingie..

what u say is that clips playd from session do not wrap position when
live is cycle-playing, right? if yes, thats fine for me...

but, like i said, i dont quite understand what this has to do
with the timeinfo stuff..


thanks, regards
°/andreas

just realised that reaktor3VSTFX does not sync propery in
live2.02 / 03...

is this working for others?
°/a

andreas wrote:not quite sure if we talk about the same thing...
what i mean is very simple:
report if the MAIN cycle modus is on or off, and
report the current cylce-settings...
NOT of any clips, the main TRANSPORT cylce !
i dont see what this has to do with clips?

it doesnt matter how clips behave in cycle mode,
its just about reporting what the user has set on the transport
thingie..

what u say is that clips playd from session do not wrap position when
live is cycle-playing, right? if yes, thats fine for me...

but, like i said, i dont quite understand what this has to do
with the timeinfo stuff..


thanks, regards
°/andreas

Andreas, Live is not like a normal Sequencer. In Live there is no one single transport as you might know it from other applications.

For your project it might be best to just report the Arranger transport. Other plugins might do something else and fail to work properly with Live.

Think you have something like a step sequencing filter plugin. This plugin modifies a audio clip with a filter. If this plugin modifies an audio clip that is not in the arranger transport (fired in session), then the plugin might come out of sync when it listens to the arranger transport cycle.

Frank

_________________
[email protected]
http://www.ableton.com

Anonymous wrote: Andreas, Live is not like a normal Sequencer. In Live there is no one single transport as you might know it from other applications.

For your project it might be best to just report the Arranger transport. Other plugins might do something else and fail to work properly with Live.

Think you have something like a step sequencing filter plugin. This plugin modifies a audio clip with a filter. If this plugin modifies an audio clip that is not in the arranger transport (fired in session), then the plugin might come out of sync when it listens to the arranger transport cycle.

Frank

hello Frank,
okay, i understand theres no one single transport in
live from lives point of view.. but..
from the plugins view, there IS one single transport in live..
(ppqPos), and ppqPos does wrap when live is cycle playing...
so..
i dont understand why other plugins would fail if live reported
its cycle-settings ..
the arranger transport already gets reported to the plugin..

why could this cause problems?
or is it that you just want that the plugins (if they have internal
sequencing) do behave like live-clips fired from session, i.e. run
independent of the arrangerTransport / cycle?

if yes, then you also have to change the ppqPos implementation in live,
cause, like said above, it does wrap and therefore behave like the
arranger transport.


sorry for all this 'fighting' ... its just that i *love* live and i would like
it to have complete vst implementation..

thanks,
°/andreas

I get your point, Andreas. It is true, that VSTTimeInfo should be changed for clips fired in Session. And then, we can also support cycle for Arranger clips. Actually thinking about it, we HAVE to change that. I think about a technical solution. No promises...
But there is still the limitation that send effects can be feeded by Session and Arranger at the same time. There is no solution for this scenario.

But I still think there is a better solution for your need. The cycle information is kind of limited. What if the song makes a jump by other means? Then your step sequencer should react to it? But there is no other information than the song position.

Hope you didn't see it as 'fight'. Please don't hesitate to point out every other VST feature that is missing...

Frank

andreas wrote:just realised that reaktor3VSTFX does not sync propery in
live2.02 / 03...

is this working for others?
°/a

What is the problem? Can you specify?

I get your point, Andreas. It is true, that VSTTimeInfo should be changed for clips fired in Session. And then, we can also support cycle for Arranger clips. Actually thinking about it, we HAVE to change that. I think about a technical solution. No promises...
But there is still the limitation that send effects can be feeded by Session and Arranger at the same time. There is no solution for this scenario.

But I still think there is a better solution for your need. The cycle information is kind of limited. What if the song makes a jump by other means? Then your step sequencer should react to it? But there is no other information than the song position.

Hope you didn't see it as 'fight'. Please don't hesitate to point out every other VST feature that is missing...

Frank

frh wrote:...It is true, that VSTTimeInfo should be changed for clips fired in Session. And then, we can also support cycle for Arranger clips. Actually thinking about it, we HAVE to change that. I think about a technical solution. No promises...
But there is still the limitation that send effects can be feeded by Session and Arranger at the same time. There is no solution for this scenario.

so the idea would be to feed vsts with DIFFERENT vstTimeinfo, depending
on if they were fired from session or arranger?

so the vst SongPosition counter for those vsts in channels that
play session clips would just increment towards 'infinity'?

where as the songposition for those channels playing arranger
stuff would be the way it is now?

is that what you mean?
then i get your point about send channels...

frh wrote:...
But I still think there is a better solution for your need. The cycle information is kind of limited. What if the song makes a jump by other means? Then your step sequencer should react to it? But there is no other information than the song position.

when songposition jumps by other means, my plugin might miss
the first step until it is in sync again...
i think this is not such a huge problem...

the problem now, when live is cycle playing, is that the plugin reads
the wrong step-position for the first step after live wraps..
not such a huge problem either, but kind of annoying when working
in the arranger, cycling specific parts ...

frh wrote: Hope you didn't see it as 'fight'. Please don't hesitate to point out every other VST feature that is missing...
Frank

glad to hear this! no, i didnt see it as a fight, just thought this might
get on your nerves... (been nagging about this timeInfostuff on here
since awhile...)
other missing stuff: samplesToNextClock
(how many samples till next 1/96 clock...)

thanks, grüsse
°/andreas

Anonymous wrote:

frh wrote:...It is true, that VSTTimeInfo should be changed for clips fired in Session. And then, we can also support cycle for Arranger clips. Actually thinking about it, we HAVE to change that. I think about a technical solution. No promises...
But there is still the limitation that send effects can be feeded by Session and Arranger at the same time. There is no solution for this scenario.

so the idea would be to feed vsts with DIFFERENT vstTimeinfo, depending
on if they were fired from session or arranger?

so the vst SongPosition counter for those vsts in channels that
play session clips would just increment towards 'infinity'?

where as the songposition for those channels playing arranger
stuff would be the way it is now?

Yes, that is what I ment.

Anonymous wrote:is that what you mean?
then i get your point about send channels...

That is the point and I don't have a solution yet.

Anonymous wrote: when songposition jumps by other means, my plugin might miss
the first step until it is in sync again...
i think this is not such a huge problem...

That is something you don't want to experience live. The Arranger cycle might have no live use, but other features that cause this behaviour in future versions of Live might target live situations.

Anonymous wrote:the problem now, when live is cycle playing, is that the plugin reads
the wrong step-position for the first step after live wraps..
not such a huge problem either, but kind of annoying when working
in the arranger, cycling specific parts ...

Are you sure? How often do you read TimeInfo?

Anonymous wrote:glad to hear this! no, i didnt see it as a fight, just thought this might
get on your nerves... (been nagging about this timeInfostuff on here
since awhile...)

No. Actually I have to thank you, because you made me aware of a problem I have to think of...

Anonymous wrote:other missing stuff: samplesToNextClock
(how many samples till next 1/96 clock...)

You can calc it yourself. Please explain for what you need this information.

Frank