I have a plug-in instrument (pluggo) that I’ve written which runs on a 1000 ms delay — it produces audio 1 second after midi, in order to glean some valuable information about note length and other musical stuff, and to buffer samples accordingly.

What I’m wondering about is what exactly Logic does in order to stop audio from my pluggo _immediately_ when I stop the transport, when audio should actually continue for 1000 ms after hitting stop? What it suggests is that Logic is actually killing dsp to my plug, which may, in turn, be causing some of my problems. What I need to know is whether there’s some way for my pluggo to detect this “stop” message, given that plugsync~ doesn’t recognize transport messages from Logic. Is there any other logical test I can do? Any sort of interruption in dsp I can somehow detect? Anything?

J.

the plug-in output is stopped for example because
of the disk buffer refresh which happens on every
stop.
i am not sure about logic, but in PT and steinberg
a “transport stop” is always a “locator set”.
if it wouldnt be, you would have to wait longer
when you press start in a project.

since you plug instruments in logic into regular
channel strips which also could point to a disk
track, it is even for instruments.

just play the stuff you need for 1000 ms longer.

I hear you… Bummer, though. It’s really awkward to
work when you can’t stop in the middle of something.

I’m messing around with trying to build a reset based
on the ticks (float), which shows up properly in plugsync~.
I’ll see how that goes. The ugly thing is that, with the
continual stopping, for some reason, my plugin behaves more
and more poorly, until it eventually freezes Logic! Ouch.

J.

J.

your only chance to avoid this is using signals only
for everything time.

well, or, where applicable, retrigger message stuff
by something signal so that you reach “sync” at least
ever 4 bars or whatever you need …

recently i discovered another simple method of
almost-timing-predictable systems for pluggo. :)
i am using a premade – in cubase – vst parameter
data track which contains sync signals, similar
like SMPTE works for audio.

routed or copied to a certain pp number in your
plug-in it can give precise timed messages and
that allows me to have a non-shifting metro
replacement based on [pp 199 foo 0 1] and
[select 0 1] which is far more accurate than even
midi from host (if the host is logic or a non-
sequencer) when you for example want to produce
1/128th note timed messages inside the plug-in.

the message data might still be delayed on their
way _in the plug-in, but at least they are _triggered
at the right moment …

I’d like to raise this topic again, especially the issue of retrieving the transport state of logic. plugsync~ doesn’t work for this and after trying all hacks and tricks I could think of (going after ticks/sample count + adding my own metro to detect change every x ms), I still don’t have a satisfying start/stop in my pluggo.

Is there anyone who found a good way to retrieve the transport state of Logic in a pluggo?

Thanks in advance,
Mattijs

In Logic, go to File>Song Settings>Synchronization and click the “MIDI” tab. Check the “Destination 1″ box and select “to Max/MSP 1″ in the drop down menu.

In Max/MSP, create an [rtin] object and connect a number box to its output

[rtin]
|
|
[numberbox]

Double click the [rtin] object and select “to Max/MSP 1″.

Now start and stop the Logic transport, and the Max/MSP number box should report the state of Logic’s transport,
where 248=play, 252=stop, etc…

Hope this is helpful to you,
Mitch

mmturner (at) mindspring (dot) com

I would be very much interested to know whether this has improved… As I recall, most sequencers had the same error, only Logic was particularly bad! ;-)

J.

Of course this way I still don’t have the info in the pluggo itsself, but perhaps there is some way to send it back to logic and put into a pluggo via some clever environment mapping..

Jb: I don’t need sync info in my pluggo but I can’t image the sample count to be inaccurate. Didn’t try though. Of course it is not a signal so you shouldn’t use that output to drive a wave~.

Cheers,
Mattijs

Aux busses, however, stay switched on. This may offer you a chance, but I have not really explored it yet.

This problem, which seems to be now “spreading” to other hosts, DP for instance, is being closely considered as part of ongoing Pluggo development.

-A

Not sure if it helps anything though….

:)

-A

The apparent “ease” of saving a Max patch as
a plug-in [and I realize that the word ease
is relative], from time to time, may mask the
fact that you *still* need to know not only
something about how Max itself runs, but about
the way that whatever application you want to
run your plug-in *with* functions – and this
may include the VST and AU plug-in specs themselves.

That would be patently and intuitively obvious
in a situation where one writes raw code, I
suppose. But it still matters here. If the VST
or AU spec specifies something, then that’s a
limitation for you [and for us, as well, since
we also write plug-ins]. And the same is true
for host applications.

uh… the documented functionality of the plugsync~ and hostsync~ objects is entirely clear. It just doesn’t quite work. I’m going to give the aux bus idea a try someday, but it’s not a priority right now. The explanation Andrew gave is perfectly reasonable, but this problem has been seen on Logic, Cubase, Live, and DP, to varying degrees of severity (Logic being the highest!). It sounds like they’re basically doing what “mute” does for the poly~ object; in this case, shutting off audio to avoid a perpetually spiked cpu!

Fair enough… I’m not bitching because I think this is c74′s fault, btw. I’m just bitching. A fix would be lovely, one day.

J.

You are right of course, this problem has nothing to do with pluggo. If the host doesn’t provide this information correctly there is no way for pluggo to send it to the user. So I blame Logic, or the AU standard, but not pluggo. Sill I was wondering whether someone found a workaround for this.

I got two replies that will work in my case: 1) the midiclock (as Mitch pointed out) and 2) the aux idea (Andrew’s finding). I really love this forum.. It works!

> The apparent “ease” of saving a Max patch as
a plug-in [and I realize that the word ease
is relative], from time to time, may mask the
fact that you *still* need to know not only
something about how Max itself runs, but about
the way that whatever application you want to
run your plug-in *with* functions – and this
may include the VST and AU plug-in specs themselves.

> That would be patently and intuitively obvious
in a situation where one writes raw code, I
suppose.

This is an interesting thing to have stated. There are several occurencies on this forum of people that have been tricked by the relative ease of max in general into believing that the underlying principles are also simple to understand without a technical background. Understanding the underlying principles gets more pressing as the ideas one tries to realize get more elaborate.

I can’t help believing that there is an accidental possibility to on one hand make people better realize this fact and on the other hand not losing a lot of artists as customers.

Ad Jb: so I believe there is nothing c74 can do about this. Except for providing a forum where users can work out workarounds together :)

Cheers,
Mattijs

My 2 cent on this:

> This is an interesting thing to have stated. There are several
> occurencies on this forum of people that have been tricked by the
> relative ease of max in general into believing that the underlying
> principles are also simple to understand without a technical
> background. Understanding the underlying principles gets more
> pressing as the ideas one tries to realize get more elaborate.
>
> I can’t help believing that there is an accidental possibility to
> on one hand make people better realize this fact and on the other
> hand not losing a lot of artists as customers.

What I like about Max and the Moore’s law is the fact that some
people with very basic programming skills will intuitively hack
something that is outside the box of a trained coder. The machines
are powerful enough not to cope with it, and there is some
interesting aesthetic findings out of that way of thinking…

I just think of some of my students with glitchy, dirty code that
sounds great… and then, I can help them to be a tad more elegant in
their coding, to consider efficient cpu cycle use and to admire
Andrew Benson receipies.

I presume it is an inheritage of my composition tutors, where I was
long ago sent to compose with a pencil, an eraser and a white
sheet… and no technique at all! And then my teachers were kind
enough to take the small good part of it and send me to the library
to listen to masterpieces without killing the fragile individual
voice being put to life in my early pieces. I prefer that apporach to
the Writing technique one.

Anyway, all that to say that it is quite easy with Pluggo and
Soundflower to put together dodgy setups with great sound results,
and I really think the Max community should continue to support the
hackers!

my 2 pennies

pa