fraudulentfromage@gmail.com

I'm contemplating a patch that would be able to keep track of the

objects in it. For example, generating a list of send & receive busses

as they are created, or simply creating a bang when a certain object

Has anyone done this? Which API (java? c++?) must I use to read these signals?

Powerbook G3/500 640/40 - Stilll great for audio!

Max/MSP, Live 4, DP4, & various hardware synths

I'm contemplating a patch that would be able to keep track of the
objects in it. For example, generating a list of send & receive busses
as they are created, or simply creating a bang when a certain object
is instantiated to trigger a counter.
Has anyone done this? Which API (java? c++?) must I use to read these signals?

---------------------
Powerbook G3/500 640/40 - Stilll great for audio!
Max/MSP, Live 4, DP4, & various hardware synths


object-creation-as-trigger

> Which API (java? c++?) must I use to read these signals?

Patch cord connections are opaque to all objects. This is an OO world 

and objects are supposed to care neither where messages come from nor 

It would presumably be possible for C74 to write a built-in object 

(like grab) that could do what you want using functions not exposed 

BTW, there is no C++ API for Max. If anything, there is a C API.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 25-Jul-2006, at 10:46, cheese wrote:
> Has anyone done this?

Patch cord connections are opaque to all objects. This is an OO world  
and objects are supposed to care neither where messages come from nor  
whence they go.

It would presumably be possible for C74 to write a built-in object  
(like grab) that could do what you want using functions not exposed  
to external APIs.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

On 25 Jul 2006, at 11:44, Peter Castine wrote:

> Patch cord connections are opaque to all objects.

nick rothwell -- composition, systems, performance -- 

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


On 25-Jul-2006, at 12:21, Nick Rothwell, quoting undersigned, wrote:

>> Patch cord connections are opaque to all objects.

Even there an object doesn't know when a patch cord has been *drawn*, 

nor what's connected to it. It's only when the user starts DSP (hit 

an ezdac~ or whatever) that an object gets told which inlets have 

On 25-Jul-2006, at 12:21, Nick Rothwell, quoting undersigned, wrote:
>> Patch cord connections are opaque to all objects.
>
> Except for DSP cords.

Even there an object doesn't know when a patch cord has been *drawn*,  
nor what's connected to it. It's only when the user starts DSP (hit  
an ezdac~ or whatever) that an object gets told which inlets have  
incoming signal vectors.

> Patch cord connections are opaque to all objects. This is an OO world 

> and objects are supposed to care neither where messages come from nor 

Perhaps I used the word signal incorrectly. I already have full access to data "flowing" across the patch cords. What I want is to simply be notified when an object (maybe a patchcords too) has been created, what type it is, its arguments, position in patcher, you know, basically just scripting in reverse. (The possibilities that jump into my head include many custom IDE capabilities, ease in learning scripting, homebrew multi-layer undo, collaborative patch editing...)

Here's my super ugly algorithm for doing this: 

rename previous save to "compare coolname"

compare "coolname" and "compare coolname" with diff

parse differences to find out what new object was created!

So there's nothing existing that can sort of do this?

> It would presumably be possible for C74 to write a built-in object 

> (like grab) that could do what you want using functions not exposed 

> BTW, there is no C++ API for Max. If anything, there is a C API.

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

> Patch cord connections are opaque to all objects. This is an OO world  
> and objects are supposed to care neither where messages come from nor  
> whence they go.

Here's my super ugly algorithm for doing this: 
(save patchers as text)
(this happens every second) 

save patcher as "coolname"
wait 1 second
rename previous save to "compare coolname"
save patcher as "coolname"
compare "coolname" and "compare coolname" with diff
parse differences to find out what new object was created!

>
> It would presumably be possible for C74 to write a built-in object  
> (like grab) that could do what you want using functions not exposed  
> to external APIs.
>
> BTW, there is no C++ API for Max. If anything, there is a C API.
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                 Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>        Interface  Building  for                   |home    | chez nous|
>        Max/MSP   Extremely cool                   |bei uns |  i nostri|
>        http://www.dspaudio.com/                   http://www.castine.de
>
>
>


AFAIR javascript have possibilities for scanning a patch for all 

objects. I am pretty sure you will find an example of this in the 

examples folder. I would start from there. Of course it won't be able to 

tell you anything about how the objects are connected.

> Here's my super ugly algorithm for doing this: (save patchers as text)

> rename previous save to "compare coolname"

> compare "coolname" and "compare coolname" with diff

> parse differences to find out what new object was created!

> So there's nothing existing that can sort of do this?

AFAIR javascript have possibilities for scanning a patch for all 
objects. I am pretty sure you will find an example of this in the 
examples folder. I would start from there. Of course it won't be able to 
tell you anything about how the objects are connected.

> Here's my super ugly algorithm for doing this: (save patchers as text)
> (this happens every second)
> save patcher as "coolname"
> wait 1 second
> rename previous save to "compare coolname"
> save patcher as "coolname"
> compare "coolname" and "compare coolname" with diff
> parse differences to find out what new object was created!
>
> seems so simple, doesn't it?
> So there's nothing existing that can sort of do this?


On 26-Jul-2006, at 12:27, Trond Lossius wrote:

> AFAIR javascript have possibilities for scanning a patch for all 

In C:    void patcher_eachdo(eachdomethod fun, void *arg);

In Javascript: x=this.patcher.firstobject, then iterate over 

What does that buy you? An object *still* doesn't know what it's 

connected to; an object doesn't even know where it's located in a 

patch. You can work around the latter limitation (more easily in 

JScript), you can't work around the first.

This thread started with some guy asking "how do I get notification 

from Max when a patch cord is drawn?" The answer is, pure and simple: 

Now the guy says he wants to poll the patcher. OK, fine. Polling 

isn't notification. It's kludgy and unreliable, and, what's worse, it 

still won't tell the guy what patch cord connections there are in a 

patch via any available Max API. His best bet for tracking patch cord 

connections is to actually save the file.

On 26-Jul-2006, at 12:27, Trond Lossius wrote:
> AFAIR javascript have possibilities for scanning a patch for all  
> objects.

In C:	void patcher_eachdo(eachdomethod fun, void *arg);
In Javascript: x=this.patcher.firstobject, then iterate over  
x=x.nextobject

What does that buy you? An object *still* doesn't know what it's  
connected to; an object doesn't even know where it's located in a  
patch. You can work around the latter limitation (more easily in  
JScript), you can't work around the first.

This thread started with some guy asking "how do I get notification  
from Max when a patch cord is drawn?" The answer is, pure and simple:  
You don't. Not from Max. Period.

Now the guy says he wants to poll the patcher. OK, fine. Polling  
isn't notification. It's kludgy and unreliable, and, what's worse, it  
still won't tell the guy what patch cord connections there are in a  
patch via any available Max API. His best bet for tracking patch cord  
connections is to actually save the file.

If I'm the "some guy", it buys me everything. I started this thread

asking how to find out if an object is present in a patch, so I can

automatically create lists of the busses present in my patch, which I

think AFAIR will do. Tracking patch cords would be cool, but I got

If I'm the "some guy", it buys me everything. I started this thread
asking how to find out if an object is present in a patch, so I can
automatically create lists of the busses present in my patch, which I
think AFAIR will do. Tracking patch cords would be cool, but I got
what I really needed. Thanks, Trond!

object creation as trigger