Hi,
I've built a step sequencer that feeds into synth plugins loaded in with vst~.
It seems to be a bit of a defect within vst~ that if I send it a lot of Noteon messages at the exact same time it drops some of them. My work around so far has been to delay the messages by about 2ms or so and it seems to play them fine.
But now I've got multiple tracks of Noteon messages coming into the one plugin loaded into vst~. With all this action happening I can't just delay each track of Noteon/off messages by say, 0ms, 2ms, 4ms, 6ms etc... as sometimes the Noteoff messages get stolen and the number of voices get maxed out and stall the plugin! (and cpu!)
I'm looking for a way to send an object (or an external) a bunch of list messages and for that object to then store them and output them at 2ms intervals in a sort of a queue.
Is there such an object?
As always, Thanks for any help you guys can provide.
John.
On Fri, 2 Oct 2009, saint wrote:
I'm looking for a way to send an object (or an external) a bunch of list messages and for that object to then store them and output them at 2ms intervals in a sort of a queue.
if the messages are all of a fixed length and all made of floats, you could look into using several [pipe] at once.
But if ever you need your messages to be more free-form (variable length, mixed symbols) you may enjoy [textfile] even though you won't be writing to files, reading from files, converting to text, or from text. It's a misnomer really.
And because you can't delete the queue items that you are done with ([textfile] only supports deleting the whole contents), then I suppose it'd be better if you use a few counters, and use a second [textfile] so that once in a while, one of the [textfile]s only contains obsolete data, so that you can clear it, so that you don't make a memory-leak.
Using externals instead of internals, you could use a single [coll], that can delete single elements. In that case you save yourself the trouble of double-buffering, but afaik you still have to use counters.
if you want something even more automatic, I haven't looked into Holzmann's containers, but I assume that they offer a lot more than either [textfile] or [coll].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Is "an instance of a data structure" synonymous with "scalar"?
append-help.pd says the first creation argument of [append] specifies the
"template of a new scalar to append," but in 4.data.structures/01.scalars.pd, it says: "Scalars are described by "templates", which are subwindows." This is problematic because if you name the subwindow "foo" and the struct contained within "bar," [append foo x y] won't work. Plus, many of the help patches have different names for the subwindow and the [struct] inside it. So what exactly is a "template"?
Ok, so three questions now: 3. In 01.scalars.pd, it also says: "Data is not persistent. If you save a Pd patch and reopen it, the "data" isn't preserved. But it is preserved (e.g., plot-help.pd). Or am I misunderstanding?
Thanks, Jonathan
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi thanks Mathieu!
i just thought of the textfile idea a while after i posted. i use one textfile that when it's caught up with it's queue it deletes it's contents and starts over.
do you think there could be a memory leak in this patch??? i use it with a 2ms interval value...
Thanks again!
John.
----- Original Message ----
From: Mathieu Bouchard matju@artengine.ca To: saint saintidle@yahoo.com Cc: pd list pd-list@iem.at Sent: Saturday, 3 October, 2009 22:49:56 Subject: Re: [PD] List Message Queueing? ( Note on/off messages into vst~ )
On Fri, 2 Oct 2009, saint wrote:
I'm looking for a way to send an object (or an external) a bunch of list
messages and for that object to then store them and output them at 2ms intervals in a sort of a queue.
if the messages are all of a fixed length and all made of floats, you could look into using several [pipe] at once.
But if ever you need your messages to be more free-form (variable length, mixed symbols) you may enjoy [textfile] even though you won't be writing to files, reading from files, converting to text, or from text. It's a misnomer really.
And because you can't delete the queue items that you are done with ([textfile] only supports deleting the whole contents), then I suppose it'd be better if you use a few counters, and use a second [textfile] so that once in a while, one of the [textfile]s only contains obsolete data, so that you can clear it, so that you don't make a memory-leak.
Using externals instead of internals, you could use a single [coll], that can delete single elements. In that case you save yourself the trouble of double-buffering, but afaik you still have to use counters.
if you want something even more automatic, I haven't looked into Holzmann's containers, but I assume that they offer a lot more than either [textfile] or [coll].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, 6 Oct 2009, saint wrote:
i just thought of the textfile idea a while after i posted. i use one textfile that when it's caught up with it's queue it deletes it's contents and starts over. do you think there could be a memory leak in this patch??? i use it with a 2ms interval value...
ah, I didn't think about your particular application, so the double-queue trick was just in case the way you use the container causes it to never catch up.
(when i say "leak" i mean just a practical leak, no matter how it happens: thus even though you can see and control the dead data in a normal way from pd, as long as the memory gets increasingly wasted and nothing is done to clean it up, it's still a leak to me, though leak-detectors wouldn't find that because they only look for "unrecoverable" leaks. in pd, those may only happen because of bugs in externals.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Jonathan Wilkes -
Mathieu Bouchard -
saint