hi olaf, hi list,
first: olaf, i had to add -DPD_0_37 to the linux CFLAGS to compile the current cvs on my machine (netclient.c failed) ... would it be possible that you change the header structure of the source or add it to your makefiles (i don't want to mess with your code)
second: i was looking for the nchange object, that works like a change, but also for symbols & lists... what do you think of changing pd's internal change to work not only on floats but also on pd's other data types? if i'm not the only one missing this feature as a core feature, i could try to add it to the cvs...
good night...
Tim Blechmann wrote:
hi olaf, hi list,
first: olaf, i had to add -DPD_0_37 to the linux CFLAGS to compile the current cvs on my machine (netclient.c failed) ... would it be possible that you change the header structure of the source or add it to your makefiles (i don't want to mess with your code)
Hi Tim,
I'm still using Pd 0.36 here, that's why it is the default in the makefile. However, I don't care if anybody changes this to Pd 0.37 in the CVS since I'll use my local copy anyway.
best, Olaf
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
what do you think of changing pd's internal change to work not only on floats but also on pd's other data types? if i'm not the only one missing this feature as a core feature, i could try to add it to the cvs...
Not a good idea, IMO. Why not write or keep it as an external? Changes to the core vocabulary shouldn't be done unless they are done in all versions of Pd.
Frank Barknecht _ ______footils.org__
Not a good idea, IMO. Why not write or keep it as an external? Changes to the core vocabulary shouldn't be done unless they are done in all versions of Pd.
i see your point ... on the other hand it's not consistent to provide several data structures (floats, symbols, lists ...) and only some of these data structures are being supported by change... imo, a _change_ for different data structures (that might be used to control the environment...) shouldn't differ from a _change_ for floats. especially if one _change_ is an internal, the other _change_ an external...
don't understand me wrong. i don't want to add a new command to the core language, i just think that it would be more consistent, if a command that would make sense for every data type only works for one...
cheers...
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
Not a good idea, IMO. Why not write or keep it as an external? Changes to the core vocabulary shouldn't be done unless they are done in all versions of Pd.
i see your point ... on the other hand it's not consistent to provide several data structures (floats, symbols, lists ...) and only some of these data structures are being supported by change...
Well, you also cannot divide symbols. ;)
Actually I wouldn't have a problem with extending change the way you suggested, but I would have a big problem with changing change so patches between the MSP and the CVS pd (or imPD) would not be exchangeable anymore. (That's a lot of change in this sentence)
Of course a a "shange" ("super change") external which will work like change for everything would be useful.
Frank Barknecht _ ______footils.org__
On Wed, 2 Jun 2004, Frank Barknecht wrote:
i see your point ... on the other hand it's not consistent to provide several data structures (floats, symbols, lists ...) and only some of these data structures are being supported by change...
Well, you also cannot divide symbols. ;)
Implementing [change] as an abstraction, you can see it depends on [==]. The notion of equality exists for Symbols. Therefore such a [change] would support Symbols if [==] did.
However another line of extension for [change] would involve some arithmetic... [change] could take a "margin of error" argument.
Mathieu Bouchard http://artengine.ca/matju