flies

this is old news, and whiny in essence, but:

it looks like onecopy wouldn't allow me to have two subpatchers who both

contain a buffer~ with name 'bufnameJesus' and have the two buffers be

On Wed, Apr 18, 2007 at 12:46 PM, Peter McCulloch 

> Try using the "onecopy" object in your patches which have sflists and

> On Apr 18, 2007, at 11:01 AM, George Locke wrote:

> i just want scoping, so i can have two copies of one external that

>> reference sflists (buffers, etc) and not have conflicts. a truly scoped

>> send object (pvar doesn't duplicate send!), and scoped references are my

>> biggest complaints about max. subpatchers should inherit scope from their

>> parent patchers, and only from their parent patchers!!!!

it looks like onecopy wouldn't allow me to have two subpatchers who both
contain a buffer~ with name 'bufnameJesus' and have the two buffers be
different, right?

On Wed, Apr 18, 2007 at 12:46 PM, Peter McCulloch 
wrote:

> Try using the "onecopy" object in your patches which have sflists and
> buffers.
>
> Peter McCulloch
>
> On Apr 18, 2007, at 11:01 AM, George Locke wrote:
>
>  i just want scoping, so i can have two copies of one external that
>> reference sflists (buffers, etc) and not have conflicts.  a truly scoped
>> send object (pvar doesn't duplicate send!), and scoped references are my
>> biggest complaints about max.  subpatchers should inherit scope from their
>> parent patchers, and only from their parent patchers!!!!
>>
>

onecopy-scoping

On Jun 13, 2008, at 2:04 PM, George Locke wrote:

> it looks like onecopy wouldn't allow me to have two subpatchers who 

> both contain a buffer~ with name 'bufnameJesus' and have the two 

Do you know about #0? If you name your buffer something like 

#0_bufnameJesus, the #0 will be substituted with a unique number when 

it's loaded. That way you'll end up with a pair of buffers named 

something like 1896_bufnameJesus and 1897_bufnameJesus.

The scope of the #0 is the patch, which means that any patch that uses 

> it looks like onecopy wouldn't allow me to have two subpatchers who  
> both contain a buffer~ with name 'bufnameJesus' and have the two  
> buffers be different, right?

Do you know about #0? If you name your buffer something like  
#0_bufnameJesus, the #0 will be substituted with a unique number when  
it's loaded. That way you'll end up with a pair of buffers named  
something like 1896_bufnameJesus and 1897_bufnameJesus.

The scope of the #0 is the patch, which means that any patch that uses  
#0 will get a unique ID.

Chris Muir
cbm@well.com	
http://www.xfade.com

#0 only works with abstractions, not with subpatchers.

Quote: george.locke.maxmsp wrote on Fri, 13 June 2008 23:30

----------------------------------------------------

> #0 only works with abstractions, not with subpatchers.

But you could put [loadmess #0] in an abstraction 'getUID' and use that to set the buffer's name..

Or you could use the oo objects if you want a real scope. Actually this question is literally covered in the oo objects help file, section 9 - generating a unique scope ID.

Quote: george.locke.maxmsp wrote on Fri, 13 June 2008 23:30
----------------------------------------------------
> #0 only works with abstractions, not with subpatchers.
>
>
----------------------------------------------------

But you could put [loadmess #0] in an abstraction 'getUID' and use that to set the buffer's name.. 

> this is old news, and whiny in essence, but:

> it looks like onecopy wouldn't allow me to have two subpatchers who both 

> contain a buffer~ with name 'bufnameJesus' and have the two buffers be 

The purpose of giving the same name is to share the buffer~ isn't it?

Just give them different names if you want different buffer~s.

This has nothing to do with onecopy at all....

George Locke schrieb:
> this is old news, and whiny in essence, but:
>
> it looks like onecopy wouldn't allow me to have two subpatchers who both 
> contain a buffer~ with name 'bufnameJesus' and have the two buffers be 
> different, right?

The purpose of giving the same name is to share the buffer~ isn't it?
Just give them different names if you want different buffer~s.
This has nothing to do with onecopy at all....

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


"The purpose of giving the same name is to share the buffer~ isn't it?"

it's nice to be able to share buffers, i guess, but unchangeable default

global for every namespace is a problem for me. It would make better sense

to me to have a special string that set special names to global.

btw, Mattjs: i'm not sure what part of the documentation you're referring

to. I'm still running 4.5 for now, but i can DL the v5 docs if you can tell

it's nice to be able to share buffers, i guess, but unchangeable default
global for every namespace is a problem for me.  It would make better sense
to me to have a special string that set special names to global.

btw,  Mattjs: i'm not sure what part of the documentation you're referring
to.  I'm still running 4.5 for now, but i can DL the v5 docs if you can tell
me where they're at.

Global has been the Max scoping paradigm since its inception.

It's not the most sophisticated scoping paradigm in computer science, but it *is* a simple and easy-to-understand model. Anything bound to a symbol is global. Period.-)

In the course of 20 or so years naturally users have felt needs for non-global scoping. So there are a couple of non-global objects (pvar, etc.), the #-0 trick, and pattr has a more sophisticated scoping model.

If you're going to work with Max, part of the deal is learning to work with its features and limitations. Buffer names are global. Period. You want non-shared buffers, you got to name 'em differently.

A man's gotta do what a man's gotta do, Arthur Putey. Ain't no use in runnin'. You gotta fight and you gotta hold your head up high. Walk tall.

(Yeahyeahyeah, I know that's not the exact quote.)

In the course of 20 or so years naturally users have felt needs for non-global scoping. So there are a couple of non-global objects (pvar, etc.), the #-0 trick, and pattr has a more sophisticated scoping model. 

(Yeahyeahyeah, I know that's not the exact quote.)


Quote: george.locke.maxmsp wrote on Tue, 17 June 2008 01:55

> btw, Mattjs: i'm not sure what part of the documentation you're referring

> to. I'm still running 4.5 for now, but i can DL the v5 docs if you can tell

Sorry, I should have been more specific. I'm talking about the oo objects recently released on my user page (cycling74.com -> Community -> user pages -> mattijskneppers.

Quote: george.locke.maxmsp wrote on Tue, 17 June 2008 01:55
----------------------------------------------------
>
> btw,  Mattjs: i'm not sure what part of the documentation you're referring
> to.  I'm still running 4.5 for now, but i can DL the v5 docs if you can tell
> me where they're at.
>

Peter, I agree that a simple model is better for beginning users, even if that means leaving out advanced features. But not for advanced users. Ideally, a model should have multiple levels of depth.

If a programming language isn't suitable for advanced use, why would beginners want to learn it?

I think Max has the potential to be a very powerful language, also and especially for complex programs. With some small additions, I believe Max can expand its target audience hugely to all programmers, not just technically inclined artists.

There are two things getting intermingled that, perhaps, need to be explicitly separated.

The one thing is programming in Max as the language exists today.

The other thing is how one would want the programming language (and environment) to evolve.

Today: buffer~ names are global. My advice to anyone wanting to program in Max *today* is to learn to work with that. My understanding is that George wants to program in Max today, which is why I was addressing that particular point. Today.

How Max might evolve... I've been pointing out that the language lacked scoping--and that this can be a real problem!--since my first Max presentation in 1991. There have been improvements on the scoping front since then. The biggest one was the pattr system. It only took just under two decades for that enhancement to develop;-) ...another reason I would not advise anyone to just wait and hold their breath until a big change to scoping capabilities are implemented;-Q

We can have a discussion about possible scoping enhancements, although I don't know to what extent ideas from outside "The Company" will actually influence future development.

yeah, thanks to everyone who put up with my belly aching. one solution i've

found to the lack of scoping is to start doing things in java.

In the meantime, i have been working with the language as it has been for

some years now, and pretty happy with it. Especially the documentation,

which is quite possibly the best documentation for any software period. So

i'm not dissatisfied by any means. Just, err, whiny.

Scoping was the one thing i wanted in max 5, but i'll be content if max 6

has it in 5-10 years. God willing i'll still be doing music then.

yeah, thanks to everyone who put up with my belly aching.  one solution i've
found to the lack of scoping is to start doing things in java.

In the meantime, i have been working with the language as it has been for
some years now, and pretty happy with it.  Especially the documentation,
which is quite possibly the best documentation for any software period.  So
i'm not dissatisfied by any means.  Just, err, whiny.

Scoping was the one thing i wanted in max 5, but i'll be content if max 6
has it in 5-10 years.  God willing i'll still be doing music then.

My last message may not have been formulated in the most optimal (let alone most diplomatic) manner, so take anything that seems too strongly worded with a grain of salt.

But those who know (connaitre/kennen/conoscere/να γνωρίστε) me know (savoir/wissen|weten/sapere/να ξέρει) that anyway.

Quote: Mattijs wrote on Tue, 17 June 2008 04:56

> I believe Max can expand its target audience hugely to all programmers, not just technically inclined artists.

This has already started happening, unless I am a fluke. A few years back I was doing all custom programming to make personalized audio software, but it was so time consuming I wasn't getting anywhere. So I looked around, found Max, and never looked back. It is so much easier to create music software by working on top of the Max platform, and the ability to change the patch on the fly while it's running opened up a whole new world for me.

Plus it's good to think of old problems in different terms. Believe it or not, learning the Max system and its limitations made me a better programmer.

Of course there is room for improvement. And I'm glad people like Mattijs and John are exploring ways around some of the current limitations. Regardless, as things stand today Max already has a ton to offer programmers!

Quote: Mattijs wrote on Tue, 17 June 2008 04:56
----------------------------------------------------
> I believe Max can expand its target audience hugely to all programmers, not just technically inclined artists.
>

This has already started happening, unless I am a fluke. A few years back I was doing all custom programming to make personalized audio software, but it was so time consuming I wasn't getting anywhere. So I looked around, found Max, and never looked back. It is so much easier to create music software by working on top of the Max platform, and the ability to change the patch on the fly while it's running opened up a whole new world for me. 

Of course there is room for improvement. And I'm glad people like Mattijs and John are exploring ways around some of the current limitations. Regardless, as things stand today Max already has a ton to offer programmers!


Quote: Peter Castine wrote on Wed, 18 June 2008 13:33

> How Max might evolve... I've been pointing out that the language lacked scoping--and that this can be a real problem!--since my first Max presentation in 1991. There have been improvements on the scoping front since then. The biggest one was the pattr system. It only took just under two decades for that enhancement to develop;-) ...another reason I would not advise anyone to just wait and hold their breath until a big change to scoping capabilities are implemented;-Q

I personally believe that the focus of cycling '74 has not been a target audience of all programmers, but only on the (rather small) group of technically inclined artists, otherwise these issues would have been addressed a long time ago. But I definitely hope that at a certain point they will expand their business model to address the larger software development community. If it was only for the money, I mean.. it's large.

> We can have a discussion about possible scoping enhancements, although I don't know to what extent ideas from outside "The Company" will actually influence future development.

I don't know whether you have time to experiment with the recently released oo objects, but if you do I would be interested in your findings. Perhaps we can convince The Company to implement these or something similar in a future release?

Quote: Peter Castine wrote on Wed, 18 June 2008 13:33
----------------------------------------------------
> How Max might evolve... I've been pointing out that the language lacked scoping--and that this can be a real problem!--since my first Max presentation in 1991. There have been improvements on the scoping front since then. The biggest one was the pattr system. It only took just under two decades for that enhancement to develop;-) ...another reason I would not advise anyone to just wait and hold their breath until a big change to scoping capabilities are implemented;-Q

>
> We can have a discussion about possible scoping enhancements, although I don't know to what extent ideas from outside "The Company" will actually influence future development.

Quote: Adam Murray wrote on Wed, 18 June 2008 21:28

> Regardless, as things stand today Max already has a ton to offer programmers!

My perception: in Max 4, four major improvements were needed to place it firmly onto the playing field of 'real' software development.

2) support for object oriented programming

3) syntax consistency (the way functionality is represented by arguments, attributes and in/outlets across objects)

4) better reliability (too many small bugs in objects, perhaps solved by tighter programming models and better testing routines)

With Max 5, point 1 is solved. With the oo objects, point 2 is solved. Which means: two down, two to go!

Quote: Adam Murray wrote on Wed, 18 June 2008 21:28
----------------------------------------------------

1) a better IDE
2) support for object oriented programming
3) syntax consistency (the way functionality is represented by arguments, attributes and in/outlets across objects)
4) better reliability (too many small bugs in objects, perhaps solved by tighter programming models and better testing routines)

onecopy, scoping