Vance Galloway

I have created a pluggo plugin that crashes in Live and Nuendo IFF (and only if) I have two or more instances of the plugin open.

This is basically a granulation plugin that reads audio either from an existing soundfile, or from a buffer.

What I suspect the problem may be is that I took little or no care to ensure that each instance of the plugin is looking at a DIFFERENT soundfile.

Therefore, when I load a specific soundfile into the buffer in one instance of the plugin, it also shows up in all of the other instances of the plugin.

I have a feeling that this is what causes the crash.

I am sure there is an easy way to ensure that I am using seperate/different sound files for each instance of the plugin - can anyone clue me in on how to ensure that this is the case?

And...perhaps "sharing" audio files is NOT what causes this problem. If anyone knows or can point me to any general information on ensuring that multiple copies of Pluggo plugins don't cause each other to crash, that would be very wonderful to learn.

Therefore, when I load a specific soundfile into the buffer in one instance of the plugin, it also shows up in all of the other instances of the plugin.  

And...perhaps "sharing" audio files is NOT what causes this problem.  If anyone knows or can point me to any general information on ensuring that multiple copies of Pluggo plugins don't cause each other to crash, that would be very wonderful to learn.

avoiding-sharing-audio-files

my guess is, that you need different names for the buffers.

so you have to create for each instance a different version of

the same granulation plug-in with different names of the buffer.

my guess is, that you need different names for the buffers.
so you have to create for each instance a different version of
the same granulation plug-in with different names of the buffer.

>my guess is, that you need different names for the buffers.

>so you have to create for each instance a different version of

>the same granulation plug-in with different names of the buffer.

...but what about automaticallly creating random names for your buffers.

>my guess is, that you need different names for the buffers.
I thik so too...

>so you have to create for each instance a different version of
>the same granulation plug-in with different names of the buffer.
...but what about automaticallly creating random names for your buffers. 

Thanks for your input. I will check this code out when I can (tonight)..

I dont' THINK that random names are going to work well in the rest of the structure of the plugin.

Isn't there a way to "reserve" the use of a file to one plugin, or one buffer player? it seems to me that there was some additional charictor that one adds as a variable to objects which indicates "this is a unique copy of this object/file". Kinda like "$"

Isn't there a way to "reserve" the use of a file to one plugin, or one buffer player?  it seems to me that there was some additional charictor that one adds as a variable to objects which indicates "this is a unique copy of this object/file".  Kinda like "$"

When I create new from the text you sent me - I get a message that "" is not included. What's this? Likely some objects I SHOULD have already.

When I create new from the text you sent me - I get a message that "" is not included. What's this?  Likely some objects I SHOULD have already.


29/06/06, kl. 3:03 +0200 , skrev Vance Galloway:

>When I create new from the text you sent me - I get a message that

>"" is not included. What's this? Likely some objects I SHOULD have

Yes, zl is part of the standard externals.

Did you copy the text from the email, and then choose "New from

>When I create new from the text you sent me - I get a message that
>"" is not included. What's this?  Likely some objects I SHOULD have
>already.

Yes, zl is part  of the standard externals.

Did you copy the text from the email, and then choose "New from
Clipboard" in the filemenu?

29/06/06, kl. 3:01 +0200 , skrev Vance Galloway:

>I dont' THINK that random names are going to work well in the rest of

>Isn't there a way to "reserve" the use of a file to one plugin, or one

>buffer player? it seems to me that there was some additional charictor

>that one adds as a variable to objects which indicates "this is a unique

>copy of this object/file". Kinda like "$"

I cant' see why it should cause any problems that several instances of

your plugin reads the same file from your harddisc. Its more of a

problem if you have more buffers with the same name.

>I dont' THINK that random names are going to work well in the rest of
>the structure of the plugin.
why not?

>
>Isn't there a way to "reserve" the use of a file to one plugin, or one
>buffer player?  it seems to me that there was some additional charictor
>that one adds as a variable to objects which indicates "this is a unique
>copy of this object/file".  Kinda like "$"
I cant' see why it should cause any problems that several instances of
your plugin reads the same file from your harddisc. Its more of a
problem if you have more buffers with the same name. 

havent done this for a while, but i seem to remember naming the buffers like this:

the 3 dashes bit is documented in pluggo docs (at the end...).

it basically makes sure that any duplicate plugins will have a different name for each instance.

not to be confused with $1 or #1 variable messages.

havent done this for a while, but i seem to remember naming the buffers like this: 

the 3 dashes bit is documented in pluggo docs (at the end...).
it basically makes sure that any duplicate plugins will have a different name for each instance.

THAT is what I remember seeing! I searched and searched last night - I may have an old version of the docs installed here. (and the app - which might explian missing the doh!)

Thanks for the tip - you know how it can be searching for info about MAX: You know that the Cycling folks provided it...it's just a matter of where it is inside some particular tutorial.

Oh - you asked why random buffer names wouldn't work - I have some other objects which need to know the names so random names would work, I'd just have to figure out how to dynamically tell these other objects "look for this specific name" whereas they are currently looking for a set name.

THAT is what I remember seeing! I searched and searched last night - I may have an old version of the docs installed here.  (and the app - which might explian missing the  doh!)

> ...but what about automaticallly creating random names for your buffers.

Much, much easier with [buffer #0anybuffername] the #0... will create a 

Sharing the same buffername should not crash, I doubt its related to that...

Jakob Riis wrote:
> ...but what about automaticallly creating random names for your buffers. 

Much, much easier with [buffer #0anybuffername] the #0... will create a 
unique number for each instance...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


makes local token to the instance of the plugin opened...

works with everything,- send & receive, messagebox, sprintf, buffer~, etc.....

it's the best way, to ensure that everything is local to the plugin,- one major advantade of --- compared to #0_ is that u can use it in abstractions as well.... 

the --- id will be the same thru all patchers, subpatchers & abstractions of the plugin...

using ---symbol,
makes local token to the instance of the plugin opened...

it's the best way, to ensure that everything is local to the plugin,- one major advantade of --- compared to #0_ is that u can use it in abstractions as well.... 
the --- id will be the same thru all patchers, subpatchers & abstractions of the plugin...

--------------------------
[buffer~ ---buffername]
[buffer~ ---buffername2]
etc....


Thank you for your input on all of this. I agree that it may not be the sharing of audio files but rather the accidental sharing of some Send/Receive message that might be the issue. The crashes seem to happen when I am manipulating the controls that define the playback location in the soundfile, and these controls use Send/Receive.

I'll go through and add "---" to a lot of my objects and see how that helps.

Thank you for your input on all of this.  I agree that it may not be the sharing of audio files but rather the accidental sharing of some Send/Receive message that might be the issue. The crashes seem to happen when I am manipulating the controls that define the playback location in the soundfile, and these controls use Send/Receive. 

Avoiding Sharing Audio Files