goodparleyandorfing

hi - is there a way to share data between identical objects in seperate sub patches without using pattr? say for instance i were to create a patch with one slider object in it and then replicate the patch ten times in seperate sub patches, what would be the most effective way to handle 'wireless' communication with just one of the patches? 

what i want to do is have one universal sequencer object that sends its control information to multiple different places exclusively - so rather than call up the individual subpatch and input the pattern i would be doing it all on one object and then sending the toggle/slider/flonum etc etc etc. data to one particular, but indentical object wirelessly.. even better would be if anyone could suggest a way of doing it in which that the universal object acts as a virtual 'control', so any changes to data would be immedietly sent to a pre-chosen destination..

hi - is there a way to share data between identical objects in seperate sub patches without using pattr? say for instance i were to create a patch with one slider object in it and then replicate the patch ten times in seperate sub patches, what would be the most effective way to handle 'wireless' communication with just one of the patches? 
what i want to do is have one universal sequencer object that sends its control information to multiple different places exclusively - so rather than call up the individual subpatch and input the pattern i would be doing it all on one object and then sending the toggle/slider/flonum etc etc etc. data to one particular, but indentical object wirelessly.. even better would be if anyone could suggest a way of doing it in which that the universal object acts as a virtual 'control', so any changes to data would be immedietly sent to a pre-chosen destination..
any ideas? thanks


sharing-data-2

I haven't done much with this, but I believe (correct me if I'm wrong)

that vade has some stuff for that. Unique identifiers for each

instance, etc. I'm sure others have similar abstractions, externals,

> hi - is there a way to share data between identical objects in seperate sub patches without using pattr? say for instance i were to create a patch with one slider object in it and then replicate the patch ten times in seperate sub patches, what would be the most effective way to handle 'wireless' communication with just one of the patches?

> what i want to do is have one universal sequencer object that sends its control information to multiple different places exclusively - so rather than call up the individual subpatch and input the pattern i would be doing it all on one object and then sending the toggle/slider/flonum etc etc etc. data to one particular, but indentical object wirelessly.. even better would be if anyone could suggest a way of doing it in which that the universal object acts as a virtual 'control', so any changes to data would be immedietly sent to a pre-chosen destination..

I haven't done much with this, but I believe (correct me if I'm wrong)
that vade has some stuff for that.  Unique identifiers for each
instance, etc.  I'm sure others have similar abstractions, externals,
but I'm not at my computer right now.

On 4/2/07, ol  wrote:
>
> hi - is there a way to share data between identical objects in seperate sub patches without using pattr? say for instance i were to create a patch with one slider object in it and then replicate the patch ten times in seperate sub patches, what would be the most effective way to handle 'wireless' communication with just one of the patches?
> what i want to do is have one universal sequencer object that sends its control information to multiple different places exclusively - so rather than call up the individual subpatch and input the pattern i would be doing it all on one object and then sending the toggle/slider/flonum etc etc etc. data to one particular, but indentical object wirelessly.. even better would be if anyone could suggest a way of doing it in which that the universal object acts as a virtual 'control', so any changes to data would be immedietly sent to a pre-chosen destination..
> any ideas? thanks
>


On 2 Apr 2007, at 19:45, keith manlove wrote:

> I haven't done much with this, but I believe (correct me if I'm wrong)

I'm of the overkill school of thought when it comes to data sharing 

in Max: I use relational databases. But that's probably just me.

> I haven't done much with this, but I believe (correct me if I'm wrong)
> that vade has some stuff for that.

I'm of the overkill school of thought when it comes to data sharing  
in Max: I use relational databases. But that's probably just me.

> On 2 Apr 2007, at 19:45, keith manlove wrote:

>> I haven't done much with this, but I believe (correct me if I'm wrong)

> I'm of the overkill school of thought when it comes to data sharing in 

> Max: I use relational databases. But that's probably just me.

Relational databases are scrutinized and optimized to a degree that the 

average Max patch data-sharing scheme never will be. They'll scale 

predictably. External databases allow all sorts of interesting 

Sure, it's overkill - no doubt about that. I don't store nearly as much 

data for Max as I do with my mail client, and credible arguments have 

been made against using databases there. (Only 15952 messages in my 

"music" archive folder.) But I've been very happy to follow your 

progress facilitating Max-database communication because I have a severe 

aversion to ugly surprises in the end stage of large projects.

I am willing to trade some constant predictable overhead for the healthy 

Nick Rothwell wrote:
>
> On 2 Apr 2007, at 19:45, keith manlove wrote:
>> I haven't done much with this, but I believe (correct me if I'm wrong)
>> that vade has some stuff for that.
>
> I'm of the overkill school of thought when it comes to data sharing in 
> Max: I use relational databases. But that's probably just me.

Relational databases are scrutinized and optimized to a degree that the 
average Max patch data-sharing scheme never will be.  They'll scale 
predictably.  External databases allow all sorts of interesting 
possibilities for data manipulation.

Sure, it's overkill - no doubt about that.  I don't store nearly as much 
data for Max as I do with my mail client, and credible arguments have 
been made against using databases there.  (Only 15952 messages in my 
"music" archive folder.)  But I've been very happy to follow your 
progress facilitating Max-database communication because I have a severe 
aversion to ugly surprises in the end stage of large projects.

I am willing to trade some constant predictable overhead for the healthy 
future of my sanity.


> But I've been very happy to follow your progress facilitating Max- 

> database communication because I have a severe aversion to ugly 

> surprises in the end stage of large projects.

I also recently had a Max/MSP based installation which needed to run 

calculations from a block of legacy code written in C, and I didn't 

have time to refactor it into an external object, so I just dug out a 

spare Mini-ITX computer, bunged Linux on it, installed MySQL, and 

populated the database via a Perl file scraper. Max/MSP on a Mac mini 

OSC is for wussies. Real programmers network their applications with 

> But I've been very happy to follow your progress facilitating Max- 
> database communication because I have a severe aversion to ugly  
> surprises in the end stage of large projects.

I also recently had a Max/MSP based installation which needed to run  
calculations from a block of legacy code written in C, and I didn't  
have time to refactor it into an external object, so I just dug out a  
spare Mini-ITX computer, bunged Linux on it, installed MySQL, and  
populated the database via a Perl file scraper. Max/MSP on a Mac mini  
then trawled the database via MXJ.

OSC is for wussies. Real programmers network their applications with  
JDBC.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


On 2 Apr 2007, at 21:22, Nick Rothwell wrote:

> OSC is for wussies. Real programmers network their applications 

Lawrence Casserley - lawrence@lcasserley.co.uk

Lawrence Electronic Operations - www.lcasserley.co.uk

Colourscape Music Festivals - www.colourscape.org.uk

> OSC is for wussies. Real programmers network their applications  
> with JDBC.
>
Oh Nick, you are a devil!! ;-)>

Lawrence Casserley - lawrence@lcasserley.co.uk
Lawrence Electronic Operations - www.lcasserley.co.uk
Colourscape Music Festivals - www.colourscape.org.uk

On 2 Apr 2007, at 21:37, lawrence casserley wrote:

>> OSC is for wussies. Real programmers network their applications 

Actually, my current toy is DataSynapse GridServer. It's big in the 

financial institutions but I reckon an MXJ library for it would be 

possible, should one want to do realtime synthesis with several 

>> OSC is for wussies. Real programmers network their applications  
>> with JDBC.
>>
> Oh Nick, you are a devil!! ;-)>

Actually, my current toy is DataSynapse GridServer. It's big in the  
financial institutions but I reckon an MXJ library for it would be  
possible, should one want to do realtime synthesis with several  
thousand servers at once.

you can share things using coll.... if you put a 1 as the second argument you won't get file not found errors. so make a

and put that exact name in each coll in whichever subpatch joo need.

you can share things using coll....  if you put a 1 as the second argument you won't get file not found errors.  so make a 

and put that exact name in each coll in whichever subpatch joo need.


> OSC is for wussies. Real programmers network their applications with JDBC.

I always had the feeling better to jump from Midi to something superior 

Instead of twirking my head with object oriented confusion, get into 

All statements without knowing what we are talking about... ;-)

Nick Rothwell schrieb:
> OSC is for wussies. Real programmers network their applications with JDBC.

Love that...
I always had the feeling better to jump from Midi to something superior 
  than OSC... ;-)

Instead of twirking my head with object oriented confusion, get into 
data based programming... ;-)

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


> (I guess it would have to be additive.)

Nick Rothwell schrieb:
> (I guess it would have to be additive.)

> hi - is there a way to share data between identical objects in

> seperate sub patches without using pattr?

Is there a specific reason why you would not want pattr? It would be the 

ol schrieb:
> hi - is there a way to share data between identical objects in
> seperate sub patches without using pattr?

Is there a specific reason why you would not want pattr? It would be the 
easiest and clearest...

Forget the patch I just sent, this is better and easier...

Forget the patch I just sent, this is better and easier...
(need more sleep... ;-)

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

On 4 Apr 2007, at 15:17, Stefan Tiedje wrote:

> Instead of twirking my head with object oriented confusion, get 

Try iBATIS or Hibernate: you get to do both at the same time...

> Instead of twirking my head with object oriented confusion, get  
> into data based programming... ;-)

sharing data