So all of the ideas from the pd~conference are still swirling around my head and slowly distilling out. One idea which I think emerged from the conference about how Pd should ideally be structured:
- high level objects for rapid programming and beginners - high level objects would be written in Pd so that the user can easily get inside it - Pd should provide a broad set of the lowest level of operators, whether they be for audio, messages, video, etc.
One key thing for this idea to work is that objects written in Pd should behave the same as those written in C, C++, etc. Things are already headed in this direction, with such new features as help patches for abstractions, etc.
I think this idea should be broadly applied in Pd and there are already a number of examples of this. A set of toxy widget abstractions would be a great solution for GUI objects, and I think the video/graphics packages already provide low level operations, it would be good to see more high level, reusable abstractions for video/graphics.
I am currently in the process of implementing a set of cross-platform objects for general access to Human Interface Devices within Pd and this idea is a central inspiration. I am implementing a HID event object then I am making objects written in Pd for higher level access, like [mouse], [joystick], [tablet], etc.
That's my two bits, I'd love to hear what others think.
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So all of the ideas from the pd~conference are still swirling around my head and slowly distilling out. One idea which I think emerged from the conference about how Pd should ideally be structured:
- high level objects for rapid programming and beginners
- high level objects would be written in Pd so that the user can easily
get inside it
- Pd should provide a broad set of the lowest level of operators,
whether they be for audio, messages, video, etc.
One key thing for this idea to work is that objects written in Pd should behave the same as those written in C, C++, etc. Things are already headed in this direction, with such new features as help patches for abstractions, etc.
I think this idea should be broadly applied in Pd and there are already a number of examples of this. A set of toxy widget abstractions would be a great solution for GUI objects, and I think the video/graphics packages already provide low level operations, it would be good to see more high level, reusable abstractions for video/graphics.
This is exactly what RRADical is about, as you probably know. I already started to implement some pdp-rrads, but generally I hope, that the rradical patches become less my project, but a community project. I'm not so much into graphics that I would be a good person to rradicalize pdp, Gem or GridFlow.
At least the ideas already developed in rradical - which mainly are: clear communication paths for remote control (also inside patches) through OSC and centralized but modular state saving - are IMO absoluetly necessary for the two R's: Rapidity and Reusability.
Ciao
- high level objects for rapid programming and beginners
- high level objects would be written in Pd so that the user can
easily get inside it
- Pd should provide a broad set of the lowest level of operators,
whether they be for audio, messages, video, etc.
i'd also suggest to provide some basic api functions for simple dsp processing to developers ... e.g. scalartimes_perform, scalartimes_simd and scalartimes_8 ... so every external programmer has easy access to the simd optimized code (_simd) without special knowledge of the platform hardware ...
that will be a bunch of exported functions (and i'm not sure if a compiler can inline these functions), but would avoid the need to reinvent the wheel a couple of times ...
cheers ... tim
On Wed, 13 Oct 2004, Hans-Christoph Steiner wrote:
So all of the ideas from the pd~conference are still swirling around my head and slowly distilling out. One idea which I think emerged from the conference about how Pd should ideally be structured:
- high level objects for rapid programming and beginners
- high level objects would be written in Pd so that the user can easily
get inside it
- Pd should provide a broad set of the lowest level of operators,
whether they be for audio, messages, video, etc.
I do agree, one of the reasons that I think that external developers should work together is to extract a common set of orthogonal, flexible objects that make up the core of pd.
I think the discussion we had about the extension of lists goes into the right direction. It might also be a good idea to figure out which of the externals can be replaced with pd internal objects, or sometimes, in which way we can expand internals so that we do not need externals (the spigot vs. gate example).
A lot of this knowledge could come from people who know pd well and are trying to build higher level abstractions like Frank does.
rradical without externals, thats what we need.
Guenter
One key thing for this idea to work is that objects written in Pd should behave the same as those written in C, C++, etc. Things are already headed in this direction, with such new features as help patches for abstractions, etc.
I think this idea should be broadly applied in Pd and there are already a number of examples of this. A set of toxy widget abstractions would be a great solution for GUI objects, and I think the video/graphics packages already provide low level operations, it would be good to see more high level, reusable abstractions for video/graphics.
I am currently in the process of implementing a set of cross-platform objects for general access to Human Interface Devices within Pd and this idea is a central inspiration. I am implementing a HID event object then I am making objects written in Pd for higher level access, like [mouse], [joystick], [tablet], etc.
That's my two bits, I'd love to hear what others think.
.hc
"Information wants to be free." -Stewart Brand
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
State-saving (pdjimmies, or RRadical or...?) has been planned for pixelTANGO. pixelTANGO uses interpolation on all controllers so it is possible to treat each ~ state as a keyframe and actually animate using them. On of the suggestions from potential users was the ability to not only save states, but actually recoded a parameter change over time and then be able to loop, stretch and play it back.
I wonder in what other ways state-saving can be expanded for usability.
Of course it would be great if state-saving was built right into PD.
B.
Frank Barknecht wrote: | Hi, | | guenter geiger wrote: | |> rradical without externals, thats what we need. | | | Word up! | | ciao
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
State-saving (pdjimmies, or RRadical or...?) has been planned for pixelTANGO. pixelTANGO uses interpolation on all controllers so it is possible to treat each ~ state as a keyframe and actually animate using them. On of the suggestions from potential users was the ability to not only save states, but actually recoded a parameter change over time and then be able to loop, stretch and play it back.
Interpolation is something I talked about with Cyrille at the convention and definitely something, I'd like to somehow integrate into Memento. However I haven't yet thought about a way that is "stupid" enough for general use here. How are you (intending to) doing it?
Of course it would be great if state-saving was built right into PD.
I had this crazy idea when talking with Miller about this, that it could be nice to extend the basic data type objects like "float" with a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 $1/freq] or even [f 0 $0/freq] to make that float value state-saveable and accessible through some OSC inlet or sender. Then the currently nessecary [commun] objects could go away, and [originator] and [caretaker] could become an ext-/internal.
Ciao
Sounds like everyone I wanted to meet made it to the conference, except me!
As for interpolation Its hard for me to see how it would work for Audio stuff in relationship to visual stuff. in pixelTANGO all parameters (rotate, scale etc..) pass through a helper abstraction that interpolates in three different ways, (based on global send-receive) including low-pass filtering, linear and no interpolation. Low-pass filtering is really smooth and great for visuals. the added benifit is that small sliders (100px wide) are really choppy for rotating say over 360degrees. The interpolation smooths out the single pixel jumps/bumps and makes a nice continuous movement. Each slider just passes through the abstraction. There is a seperate abstraction that send the "smoothness" value and type to all the interpolation abstractions.
Its on by default and users just use and and say "wow, that is smooth". I guess the basic lesson is that pretty well every gem paramter can be very well interpolated. (things like video clip in and out points are not interpolated)
What I've done with pixelTANGO is get away from what v_ was doing (a separate OSC name for each abstraction). So that a higher-level structure would have an OSC name and any sub-modules would have a set OSC structure. For example you have a layer with a translate and rotate objects (as separate abstractions). You add a single OSC abstraction with a name like /layer1 and then OSC messages like "/layer1/translate/x" get trapped by the correct abstraction. (no support for dealing with multiple translate abstractions in one chain.)
Right now the control bus just prepends a string to set the destination (like text) but just using OSC formatted messages for interal communication would have significant advantages.
Ok all that was to say that its most flexible and modular to have a number of float values that have OSC names. I wonder if there would be a way to have a standard OSC namespace for a patch that all objects can be referenced via OSC something like /[patchname]/[abstraction-name]/f1 for first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Interpolation is something I talked about with Cyrille at the convention and definitely something, I'd like to somehow integrate into Memento. However I haven't yet thought about a way that is "stupid" enough for general use here. How are you (intending to) doing it?
Of course it would be great if state-saving was built right into PD.
I had this crazy idea when talking with Miller about this, that it could be nice to extend the basic data type objects like "float" with a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 $1/freq] or even [f 0 $0/freq] to make that float value state-saveable and accessible through some OSC inlet or sender. Then the currently nessecary [commun] objects could go away, and [originator] and [caretaker] could become an ext-/internal.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Thu, 14 Oct 2004, B. Bogart wrote:
Right now the control bus just prepends a string to set the destination (like text) but just using OSC formatted messages for interal communication would have significant advantages.
Is there a reason why this has to be done with OSC messages instead of pd messages ? IMO opinion it makes pd harder to use if you mix concepts. Is there a significant improvement from using /[patchname]/[abstraction-name]/f1 over [patchname] [abstraction-name] f1 ?
(except the spaces problem, which has to be solved separately)
I even think that the OSC messages should be converted into pd messages immediately, without using the OSCroute object.
Well, a question of taste, but thats my taste anyhow. same for naming of states. should be symbols IMO, without "/"
Ok all that was to say that its most flexible and modular to have a number of float values that have OSC names. I wonder if there would be a way to have a standard OSC namespace for a patch that all objects can be referenced via OSC something like /[patchname]/[abstraction-name]/f1 for
One problem might be that this naming is ambiguous, there could be hundreds of /[patchname]/[abstraction-name]/f1
first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
Great idea, but again, why has this to be done with OSC ? I am very much for OSC compatibility of pd, but we should not change the style of the pd language for that. I think this would be possible to be implemented in pd messages instead of OSC messages. Just replace the "/" by a " ".
Guenter
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Interpolation is something I talked about with Cyrille at the convention and definitely something, I'd like to somehow integrate into Memento. However I haven't yet thought about a way that is "stupid" enough for general use here. How are you (intending to) doing it?
Of course it would be great if state-saving was built right into PD.
I had this crazy idea when talking with Miller about this, that it could be nice to extend the basic data type objects like "float" with a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 $1/freq] or even [f 0 $0/freq] to make that float value state-saveable and accessible through some OSC inlet or sender. Then the currently nessecary [commun] objects could go away, and [originator] and [caretaker] could become an ext-/internal.
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Thu, 14 Oct 2004, B. Bogart wrote:
first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
Great idea, but again, why has this to be done with OSC ? I am very much for OSC compatibility of pd, but we should not change the style of the pd language for that. I think this would be possible to be implemented in pd messages instead of OSC messages. Just replace the "/" by a " ".
You miss one central feature of OSC: pattern matching. This is very useful, as I can access lots of values at the same time:
"/sequencer/volume* 100" will set all 64 volume sliders to 100.
Ciao
On Fri, 15 Oct 2004, Frank Barknecht wrote:
Great idea, but again, why has this to be done with OSC ? I am very much for OSC compatibility of pd, but we should not change the style of the pd language for that. I think this would be possible to be implemented in pd messages instead of OSC messages. Just replace the "/" by a " ".
You miss one central feature of OSC: pattern matching. This is very useful, as I can access lots of values at the same time:
"/sequencer/volume* 100" will set all 64 volume sliders to 100.
I see, but that can be solved. "route" could be changed to do pattern matching.
That is a good example of what I actually wanted to say, I think that it is important to do this the "pd way". Extend the language of pd where parts are missing. This is the only way to keep the "pd language" compact and consistent.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Fri, 15 Oct 2004, Frank Barknecht wrote:
You miss one central feature of OSC: pattern matching. This is very useful, as I can access lots of values at the same time:
"/sequencer/volume* 100" will set all 64 volume sliders to 100.
I see, but that can be solved. "route" could be changed to do pattern matching.
I would generally have no problem with replacing the OSC-messages for rrad-internal messages with lists.
But I would need to solve another thing: The fact, that OSC message targets are just a single atom in Pd, and not a list, while they still can describe hierarchies of e.g. abstractions.
This is very useful, if you want to "pack" lists into abstraction arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas [route]-lingo would need $1-4 for the same: "myabs synths fm carrier".
Now someone might suggest to pack the 4-element list with something like "list2symbol" in advance. But in fact that only brings us back to OSC formatted messages. ;)
Ciao
On Fri, 15 Oct 2004, Frank Barknecht wrote:
I would generally have no problem with replacing the OSC-messages for rrad-internal messages with lists.
But I would need to solve another thing: The fact, that OSC message targets are just a single atom in Pd, and not a list, while they still can describe hierarchies of e.g. abstractions.
This is very useful, if you want to "pack" lists into abstraction arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas [route]-lingo would need $1-4 for the same: "myabs synths fm carrier".
Now someone might suggest to pack the 4-element list with something like "list2symbol" in advance. But in fact that only brings us back to OSC formatted messages. ;)
.. and it would be a terribly ugly solution too.
Mhmm,
Guenter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On the note of using Pd message in this way...
how about a standard "prepend" internal? :)
B.
guenter geiger wrote: | On Fri, 15 Oct 2004, Frank Barknecht wrote: | |>I would generally have no problem with replacing the OSC-messages for |>rrad-internal messages with lists. |> |>But I would need to solve another thing: The fact, that OSC message |>targets are just a single atom in Pd, and not a list, while they still |>can describe hierarchies of e.g. abstractions. |> |>This is very useful, if you want to "pack" lists into abstraction |>arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas |>[route]-lingo would need $1-4 for the same: "myabs synths fm carrier". |> |>Now someone might suggest to pack the 4-element list with something |>like "list2symbol" in advance. But in fact that only brings us back to |>OSC formatted messages. ;) | | | .. and it would be a terribly ugly solution too. | | Mhmm, | | Guenter | | | _______________________________________________ | PD-dev mailing list | PD-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/pd-dev |
That was discussed at pd~conf. I think Miller is going to include [prepend] soon.
.hc
On Oct 15, 2004, at 1:31 PM, B. Bogart wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On the note of using Pd message in this way...
how about a standard "prepend" internal? :)
B.
guenter geiger wrote: | On Fri, 15 Oct 2004, Frank Barknecht wrote: | |>I would generally have no problem with replacing the OSC-messages for |>rrad-internal messages with lists. |> |>But I would need to solve another thing: The fact, that OSC message |>targets are just a single atom in Pd, and not a list, while they still |>can describe hierarchies of e.g. abstractions. |> |>This is very useful, if you want to "pack" lists into abstraction |>arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas |>[route]-lingo would need $1-4 for the same: "myabs synths fm carrier". |> |>Now someone might suggest to pack the 4-element list with something |>like "list2symbol" in advance. But in fact that only brings us back to |>OSC formatted messages. ;) | | | .. and it would be a terribly ugly solution too. | | Mhmm, | | Guenter | | | _______________________________________________ | PD-dev mailing list | PD-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/pd-dev | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBcAlvjbOsMZSA25cRAstZAKC+VrJ4lY0Hsb/2V7d6OE/qlH4EgQCeP8Md Lsq+5cnZL/k0MlVSbzHdFyc= =N7s3 -----END PGP SIGNATURE-----
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Fri, 15 Oct 2004, Frank Barknecht wrote:
Now someone might suggest to pack the 4-element list with something like "list2symbol" in advance. But in fact that only brings us back to OSC formatted messages. ;)
.. and it would be a terribly ugly solution too.
Hm, and it wouldn't work for abstraction arguments anyway, as now occured to me. ;)
Ciao
On Fri, 15 Oct 2004, Frank Barknecht wrote:
I see, but that can be solved. "route" could be changed to do pattern matching.
I would generally have no problem with replacing the OSC-messages for rrad-internal messages with lists.
But I would need to solve another thing: The fact, that OSC message targets are just a single atom in Pd, and not a list, while they still can describe hierarchies of e.g. abstractions.
This is very useful, if you want to "pack" lists into abstraction arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas [route]-lingo would need $1-4 for the same: "myabs synths fm carrier".
Thinking about that I am not even sure if the possibility to send to /myabs/synths/fm/carrier directly is such a good thing, as it completely destroys encapsulation of abstractions. all /myabs messages should be handled by myabs and its subpatches.
Otherwise I can just hookup any receiver to /myabs/synths/fm/carrier and create a complete mess ... if I am not very careful.
Forcing decomposition of message hierarchies into the objects where they belong seem to be a restriction that actually helps to write better code.
Another problem is that a route with wildcards is not enough, what we would need additionally is a "receive" with wildcards.
I am still trying to follow the pd train of thought instead of thinking OSC ... If we are weak now, we will end up like C++, which has, in fact, its good additions, but there are too many bad ones and it generally ended up being a collection of concepts. It has its followers, though.
Guenter
Now someone might suggest to pack the 4-element list with something like "list2symbol" in advance. But in fact that only brings us back to OSC formatted messages. ;)
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Fri, 15 Oct 2004, Frank Barknecht wrote:
But I would need to solve another thing: The fact, that OSC message targets are just a single atom in Pd, and not a list, while they still can describe hierarchies of e.g. abstractions.
This is very useful, if you want to "pack" lists into abstraction arguments. $1 in OSC lingo can be "/myabs/synths/fm/carrier" whereas [route]-lingo would need $1-4 for the same: "myabs synths fm carrier".
Thinking about that I am not even sure if the possibility to send to /myabs/synths/fm/carrier directly is such a good thing, as it completely destroys encapsulation of abstractions. all /myabs messages should be handled by myabs and its subpatches.
Just to clarify this: In memento, I'm not using any global receivers at all (except one). So the "r /myabs/whatever] thing is not a part of Memento, and I agree, that this would be bad for encapsulation which is no problem in "single user" patches, but encapsulation is crucial for abstraction libraries.
All remote control from outside an abstraction is running through inlets, not receivers.
Another problem is that a route with wildcards is not enough, what we would need additionally is a "receive" with wildcards.
I don't see, where a wildcard-receive would be necessary in this context?
Ciao
On Sun, 17 Oct 2004, Frank Barknecht wrote:
Thinking about that I am not even sure if the possibility to send to /myabs/synths/fm/carrier directly is such a good thing, as it completely destroys encapsulation of abstractions. all /myabs messages should be handled by myabs and its subpatches.
Just to clarify this: In memento, I'm not using any global receivers at all (except one). So the "r /myabs/whatever] thing is not a part of Memento, and I agree, that this would be bad for encapsulation which is no problem in "single user" patches, but encapsulation is crucial for abstraction libraries.
All remote control from outside an abstraction is running through inlets, not receivers.
Ah, I see ...
Another problem is that a route with wildcards is not enough, what we would need additionally is a "receive" with wildcards.
I don't see, where a wildcard-receive would be necessary in this context?
Hmm, most likely I had a knot in my brain. I was thinking about the wildcard feature of OSC. A user who wants to have [receive]'s in the abstractions instead of passing through inlets. But then you would need the wildcards in [send]'s in order to access more than one receiver, not in the receive's.
Does this make more sense ?
Guenter
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Hmm, most likely I had a knot in my brain. I was thinking about the wildcard feature of OSC. A user who wants to have [receive]'s in the abstractions instead of passing through inlets. But then you would need the wildcards in [send]'s in order to access more than one receiver, not in the receive's.
Yes, wildcards in sends makes more sends, sorry, sense.
In OSC, only "sends" have wildcards: "/synth*/freq 120". The only "half-wildcard" allowed in OSC targets (receives) is the literal /* which strips off the first element.
This is so, because matching patterns with patterns is quite difficult.
Ciao
hy, just a couple eurocents
_the_ advantage of doing stuff in osc in my opinion is the interchangeability of implementations of e.g. synths or control generators / interfaces across different implementation platforms. this doesnt necessarily mean that pd internally has to adopt the osc syntax for message routing.
if theres some automatic conversion from incoming osc to pd's internal message format, respectively outgoing, thats great of course.
i also see the ambiguity problem of /patchname/abstractionname but cant this be solved simply with appending $0 after the abstractionname? ok, this doesnt work for subpatches.
re OSCroute: at the moment i m hardly using OSCroute at all but
dumpOSC | sprinkler
and then do a
r /patch/paramname
if r can do wildcards that could also be helpful if using pd's native msg format, no?
bst, opt
[guenter geiger]->[Re: [PD-dev] an idea for Pd structure]->[04-10-15 11:16]
| |On Thu, 14 Oct 2004, B. Bogart wrote: |> Right now the control bus just prepends a string to set the destination |> (like text) but just using OSC formatted messages for interal |> communication would have significant advantages. | |Is there a reason why this has to be done with OSC messages instead |of pd messages ? IMO opinion it makes pd harder to use if you mix |concepts. Is there a significant improvement from using |/[patchname]/[abstraction-name]/f1 over |[patchname] [abstraction-name] f1 ? | |(except the spaces problem, which has to be solved separately) | |I even think that the OSC messages should be converted into pd messages |immediately, without using the OSCroute object. | |Well, a question of taste, but thats my taste anyhow. same for naming |of states. should be symbols IMO, without "/" | |> |> Ok all that was to say that its most flexible and modular to have a number |> of float values that have OSC names. I wonder if there would be a way to |> have a standard OSC namespace for a patch that all objects can be |> referenced via OSC something like /[patchname]/[abstraction-name]/f1 for | |One problem might be that this naming is ambiguous, there could be |hundreds of /[patchname]/[abstraction-name]/f1 | |> first float. I think OSC really becomes powerful when the namespace |> reflects the structure of the patch, rather than being wholly generated |> and imagined by the user. this opens the door to extracting the function |> of a patch from the OSC namespace and simply being able to standardize so |> that patches not made to work together over OSC magically do. | |Great idea, but again, why has this to be done with OSC ? |I am very much for OSC compatibility of pd, but we should not change the |style of the pd language for that. I think this would be possible to |be implemented in pd messages instead of OSC messages. Just replace the |"/" by a " ". | |Guenter | |> |> > Hallo, |> > B. Bogart hat gesagt: // B. Bogart wrote: |> > |> > |> > Interpolation is something I talked about with Cyrille at the |> > convention and definitely something, I'd like to somehow integrate |> > into Memento. However I haven't yet thought about a way that is |> > "stupid" enough for general use here. How are you (intending to) doing |> > it? |> > |> >> Of course it would be great if state-saving was built right into PD. |> > |> > I had this crazy idea when talking with Miller about this, that it |> > could be nice to extend the basic data type objects like "float" with |> > a OSC-tag. Instead of [float 0] ony would write [float 0 /freq], [f 0 |> > $1/freq] or even [f 0 $0/freq] to make that float value state-saveable |> > and accessible through some OSC inlet or sender. Then the currently |> > nessecary [commun] objects could go away, and [originator] and |> > [caretaker] could become an ext-/internal. |> > |> > Ciao |> > -- |> > Frank Barknecht _ ______footils.org__ |> > |> > _______________________________________________ |> > PD-dev mailing list |> > PD-dev@iem.at |> > http://iem.at/cgi-bin/mailman/listinfo/pd-dev |> > |> |> |> |> _______________________________________________ |> PD-dev mailing list |> PD-dev@iem.at |> http://iem.at/cgi-bin/mailman/listinfo/pd-dev |> | | |_______________________________________________ |PD-dev mailing list |PD-dev@iem.at |http://iem.at/cgi-bin/mailman/listinfo/pd-dev |
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
Sounds like everyone I wanted to meet made it to the conference, except me!
A pity. :(
As for interpolation Its hard for me to see how it would work for Audio stuff in relationship to visual stuff. in pixelTANGO all parameters (rotate, scale etc..) pass through a helper abstraction that interpolates in three different ways, (based on global send-receive) including low-pass filtering, linear and no interpolation.
What I actually I'm contemplating is not so much how to interpolate (there are various ways to do that including line~ etc.) but how to integrate interpolation into state saving. Saved states only can contain static values, that is e.g. start and end points of a movement, that is interpolated. The actual interpolation would need to happen outside of the state saving system itself. In Memento, saving state and OSC are quite coupled currently: Every state variable is also a OSC target. I'm wondering if this connection should be broken up.
What I've done with pixelTANGO is get away from what v_ was doing (a separate OSC name for each abstraction). So that a higher-level structure would have an OSC name and any sub-modules would have a set OSC structure. For example you have a layer with a translate and rotate objects (as separate abstractions). You add a single OSC abstraction with a name like /layer1 and then OSC messages like "/layer1/translate/x" get trapped by the correct abstraction. (no support for dealing with multiple translate abstractions in one chain.)
This last problem doesn't sound too good, IMO. I need support for multiple objects of the same type in one abstraction. For example the adsr normally is used several times in one synth abstraction.
I thought about explicitly including the abstraction name into Memento and not relying on the $1-argument, but I decided against this. I would always need $1 anyway to be able to differentiate between abstraction instances of the same type. Using the abstraction name for generating OSC target names would only make it harder to create name clashes, but doesn't have any advantage besides that, as far as I can see.
I also don't use global sends at all except where global access is intentional. All Originators share only one single receiver: "r SET_ALL_RRADICALS" which is sometimes handy for changing the active state of *all* used abstractions. This is the *only* non-$0 name used in Memento. Keeping a strict border between abstractions is absolutely crucial for reusability, IMO. I explain my reasoning for that encapsulation in the RRADical doc for my talk in Graz: "Strict borders. One and only one border crossing"
Ok all that was to say that its most flexible and modular to have a number of float values that have OSC names. I wonder if there would be a way to have a standard OSC namespace for a patch that all objects can be referenced via OSC something like /[patchname]/[abstraction-name]/f1 for first float. I think OSC really becomes powerful when the namespace reflects the structure of the patch, rather than being wholly generated and imagined by the user. this opens the door to extracting the function of a patch from the OSC namespace and simply being able to standardize so that patches not made to work together over OSC magically do.
This is definitely something interesting. However another design goal in Memento is: "Not everything wants to be saved." I don't want to have to save every single float number I use in an abstraction. Most of the floats are just throw-away computational results without any real meaning that would describe, what the "state" of my patch is like. To me, this reflects Miller's original approach: Only save, what is explicitly visible. [loadbang]---[2(---[...] is explicit, [f 3] is explicit, [f] isn't.
So IMO the user should be able to specify, what is part of a "state" and what is not. This is, what the [commun] objects in Memento do: make the state explicit and visible. Doing this inside Pd would for example be possible with the idea I already mentioned: OSC- or receiver-extended atoms like [float 0 /frequency] and [symbol loop.wav /sample]. Those targets then could be magically collected into an [originator] object, if needed, which also handles remote control, and saved using some [caretaker] objects of various types like [caretaker-netsend], [caretaker-textfile], [caretaker-cvs], ...
Ciao
hello,
Frank Barknecht wrote:
What I actually I'm contemplating is not so much how to interpolate (there are various ways to do that including line~ etc.) but how to integrate interpolation into state saving. Saved states only can contain static values, that is e.g. start and end points of a movement, that is interpolated. The actual interpolation would need to happen outside of the state saving system itself.
I would personaly prefere something like adding a message to memento : "interpolsub 1 0.1 2 0.4 4 0.5" that would work like setsub but in this exemple the result would be : 0.1 * substrate 1 + 0.4 * sub2 + 0.5 * sub4.
(does it make sense?)
by this way, interpolation could not be include in state saving, but only in state restoring...
it's a good generic way for parametter interpolation, that does not nead to change lot of thing to the curent implementation.
maybe adding fonctionality to pool would be the simpliest way to do this...
cyrille
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
I would personaly prefere something like adding a message to memento : "interpolsub 1 0.1 2 0.4 4 0.5" that would work like setsub but in this exemple the result would be : 0.1 * substrate 1 + 0.4 * sub2 + 0.5 * sub4.
(does it make sense?)
by this way, interpolation could not be include in state saving, but only in state restoring...
it's a good generic way for parametter interpolation, that does not nead to change lot of thing to the curent implementation.
One problem is, that the Memento system doesn't care about types. You can save everything, even floats and lists. And "0.1 * loop.wav" is difficult to interpret.
Wouldn't most interpolation issues be possible to solve with a kind of stored envelope? Like an ADSR also describes an interpolation, but it still can be stored using four static values.
Ciao
One problem is, that the Memento system doesn't care about types. You can save everything, even floats and lists. And "0.1 * loop.wav" is difficult to interpret.
in the system I'm curently using (made around a custom pbank object) list are interpolated element by element (if the 2 interpolated list are the same size). the possibility to have symbol instead of float is the solution not to interpol every value. exemple of what is currently running on my computer :
preset_default : 1 2 3 4 5 6 7 8 9 110 preset_1 : 4 5 6 7 8 9 1 2 3 foo preset_2 : 1 3 5 7 9 1 3 5 7 foo preset_3 : 2 2 2 2 2 2 2 2 2 foo preset_4 : 0 9 0 9 0 9 0 9 0 foo
default preset is load on startup. then I just have interpolation beetween preset 1, 2, 3 and 4 :
out = preset_1 * C1 + preset_2 * C2 ...
the 110 value of the preset_default is in this exemple the volume. this value can not be interpolized (foo), so interpolating will not occur for this specific parametter. in fact, I use a lots the list of float/symbol in my interpolation preset system.
Wouldn't most interpolation issues be possible to solve with a kind of stored envelope? Like an ADSR also describes an interpolation, but it still can be stored using four static values.
weel, I don't see how an ADSR can help for interpolation. maybe I did not really undersant what you thinking of.
cyrille
Ciao
Hallo,
(I might answer to the other part of your email after some more thinking about it...)
cyrille henry hat gesagt: // cyrille henry wrote:
Wouldn't most interpolation issues be possible to solve with a kind of stored envelope? Like an ADSR also describes an interpolation, but it still can be stored using four static values.
weel, I don't see how an ADSR can help for interpolation. maybe I did not really undersant what you thinking of.
I mentioned the ADSR as an example for how to save an interpolation. An ADSR is just four numbers specifying the state: "adsr 10 100 0.9 200". However those four values are used to interpolate another value: the volume of a signal for example - this is enveloped interpolation. One never uses the A,D,S and R values directly. Thus the A,D,S and R values are very much like the C1, C2,... in your example.
Using this to handle interpolation would involve to do the actual interpolation outside the state saving system.
For example like this:
[state-holder] <---------- stores state1, state2,... with stateX for | example being (list 1 3 2 4 3 5) | state 2 being (list 7 6 8 7 9 0) etc. | [envelope-generator] <--- stores C1, C2, C3,... | has e.g. a [Cx 100(---[line~] construct | inside. Also has a volatile storage for | stateX lists. ...
Using this, one would select the wanted Cx variable(s), then use [state-holder] to send a list to [envelope-generator], then send another list, which [envelope-generator] will interpolate.
As Memento will save everything used in a patch, the envelope interpolation values would be saved as well as the stateX lists.
Do I make sense? ;)
Ciao
I mentioned the ADSR as an example for how to save an interpolation. An ADSR is just four numbers specifying the state: "adsr 10 100 0.9 200". However those four values are used to interpolate another value: the volume of a signal for example - this is enveloped interpolation.
ok, it's just a question of word. for me an adsr is not interpolation because time is part of the adsr, but not for (my vision of ) the interpolation.
my vision of interpolation is more or less something like this :
http://cnmat.cnmat.berkeley.edu/~ali/documents/intuition.pdf
using [line] for interpolation is far away of what I nead for my specific use...
cyrille
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
ok, it's just a question of word. for me an adsr is not interpolation because time is part of the adsr, but not for (my vision of ) the interpolation.
But time is just a float! ;)
my vision of interpolation is more or less something like this :
http://cnmat.cnmat.berkeley.edu/~ali/documents/intuition.pdf
using [line] for interpolation is far away of what I nead for my specific use...
I'm downloading this now and will read it, but I'd like to say, that [line] is just one form of what I proposed. Replacing [line] with [*] and thereby making the process time-independent would not change the general principle, or would it?
Bare with me, I'm just trying to build a bridge from the way I'm used to think to your way of approaching things.
Ciao
Hallo, cyrille henry hat gesagt: // cyrille henry wrote:
in the system I'm curently using (made around a custom pbank object) list are interpolated element by element (if the 2 interpolated list are the same size). the possibility to have symbol instead of float is the solution not to interpol every value. exemple of what is currently running on my computer :
preset_default : 1 2 3 4 5 6 7 8 9 110 preset_1 : 4 5 6 7 8 9 1 2 3 foo preset_2 : 1 3 5 7 9 1 3 5 7 foo preset_3 : 2 2 2 2 2 2 2 2 2 foo preset_4 : 0 9 0 9 0 9 0 9 0 foo
default preset is load on startup. then I just have interpolation beetween preset 1, 2, 3 and 4 :
out = preset_1 * C1 + preset_2 * C2 ...
Action speaks louder than words: I tried to mimick this with Memento in attached patches, which require Memento of course + zexy. (tester.pd is the main patch). I omitted the final summing into "out", though, but that's trivial. I also left out the "symbol in list" part, which cannot be used with [pack] and [unpack], but should work in Memento itself, if you don't care about editing the lists using Pd. (Just use [drip]---[route float] in interpolator.pd then.)
Generally it works, but it also showed some problems with the way, current Memento is saving substates and declaring variable names. Basically it boils down to this: It is not easily possible to have an unknown number of variables inside a state - besides the main "preset" or "substate" variable, which can be infinite.
What I mean is this: You can in theory have an infinite amount of "presets", but you cannot have variables in it, whose names are not known in advance. So this is impossible:
/synth/preset 0 /synth/setting1 1 3298 44 /synth/setting2 3 8 429 /synth/setting3 1929 1 46569 ...
unless you know, how many settingX variables you will need. The set of "keys" in the stored "key:value" pairs needs to be known. in advance.
OTOH this is possible:
/synth/preset 0 /synth/setting 1 3298 44 /synth/preset 1 /synth/setting 3 8 429 /synth/preset 2 /synth/setting 1929 1 46569 /synth/preset ...
It maybe would be nice to be able to create settings using the first way, but currently that's not the way, Memento is designed, you have to take the second approach.
However I'm not really sure yet, if this application actually should be part of a state saving system. I would probably use some other object, abstraction or custom external, to create this kind of interpolation, and only use Memento to store the coordinates of the preset, you want to interpolate.
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
cyrille henry hat gesagt: // cyrille henry wrote:
in the system I'm curently using (made around a custom pbank object) list are interpolated element by element (if the 2 interpolated list are the same size). the possibility to have symbol instead of float is the solution not to interpol every value. exemple of what is currently running on my computer :
preset_default : 1 2 3 4 5 6 7 8 9 110 preset_1 : 4 5 6 7 8 9 1 2 3 foo preset_2 : 1 3 5 7 9 1 3 5 7 foo preset_3 : 2 2 2 2 2 2 2 2 2 foo preset_4 : 0 9 0 9 0 9 0 9 0 foo
Action speaks louder than words: I tried to mimick this with Memento in attached patches, which require Memento of course + zexy.
More loud action regarding this cute problem: tester2.pd shows some more ideas in this interpolation business, which I'd prefer to call weighting actually (like in "weighted sum").
Now I abstracted out the weighting into a list scale abstraction rrad.lscale, which simply scales all floats in a list by some value, then sends out the scaled list. This maybe should be an external in the end, because it's probably called many times and has to be fast.
Then tester2.pd uses this rrad.lscale in two ways: One is for scaling OSC messages, as they are put out or accepted in the OSC-xlets of rradical patches. This will let one abstraction scale another one of the same type (or at least with the same OSC-target names). However this will not easily let a change of scaling factor trigger a change of the child abstraction's settings.
This is possible with the second approach I took in the same patch: Here I use a wrapper around [commun] which decorates commun with a second outlet for scaled values. Scaling (weighting, interpolation) then is simply possible by replacing [commun]-objects with [lscale-commun]-objects and reading out the scaled outlet. The example abstraction lscale-sliders.pd has such a scaler inside.
Is this any good?
Ciao
State saving is already built into Pd, thanks to RRADical. The main reason that I am bringing up this topic of discussion is that I think its a paradigm shift in the way most people think of Pd. It was for me, and now I am a convert, thanks to the pd~convention.
Most great computer languages are largely built using themselves. C, Java, Objective-C, Smalltalk, Forth, etc. etc. These are all languages where most of the APIs and even the compilers are written in the same language. I think Pd should be the same.
So I think the key work ahead to make this a reality is to make objects written in Pd behave transparently, as if they were written in C, when using them. AFAIK, this work is mostly done.
.hc
On Oct 14, 2004, at 12:55 PM, B. Bogart wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
State-saving (pdjimmies, or RRadical or...?) has been planned for pixelTANGO. pixelTANGO uses interpolation on all controllers so it is possible to treat each ~ state as a keyframe and actually animate using them. On of the suggestions from potential users was the ability to not only save states, but actually recoded a parameter change over time and then be able to loop, stretch and play it back.
I wonder in what other ways state-saving can be expanded for usability.
Of course it would be great if state-saving was built right into PD.
B.
Frank Barknecht wrote: | Hi, | | guenter geiger wrote: | |> rradical without externals, thats what we need. | | | Word up! | | ciao -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBbq+TjbOsMZSA25cRAnTZAKDOv6WyAgKy7OPiw3HpzTHH1hEIQACgpjz8 BIzjdsU981JP6ikvbbhWAQ0= =SJO6 -----END PGP SIGNATURE-----
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
hi hans
Most great computer languages are largely built using themselves. C, Java, Objective-C, Smalltalk, Forth, etc. etc. These are all languages where most of the APIs and even the compilers are written in the same language. I think Pd should be the same.
i must say, i don't really agree with what you suggest ... building a c-compiler in c is probably a good task for c, but a pd build system in pd? i doubt that something like that would work ...
pd is a language ... and a very powerful language in the fields where it is built for ... but there are tasks where another language might be better ... maybe that's why there are extensions to access c, python, scheme, ruby, forth (... ???) from pd ...
i'm not against patching at all, but there are certain tasks, that can be realized within python or k_cext within 30 minutes, that would take (at least for me) several hours ...
cheers ... tim
On Oct 14, 2004, at 6:31 PM, Tim Blechmann wrote:
hi hans
Most great computer languages are largely built using themselves. C, Java, Objective-C, Smalltalk, Forth, etc. etc. These are all languages where most of the APIs and even the compilers are written in the same language. I think Pd should be the same.
i must say, i don't really agree with what you suggest ... building a c-compiler in c is probably a good task for c, but a pd build system in pd? i doubt that something like that would work ...
pd is a language ... and a very powerful language in the fields where it is built for ... but there are tasks where another language might be better ... maybe that's why there are extensions to access c, python, scheme, ruby, forth (... ???) from pd ...
i'm not against patching at all, but there are certain tasks, that can be realized within python or k_cext within 30 minutes, that would take (at least for me) several hours ...
I didn't mean to suggest that we implement a build system in Pd, I wasn't the best example of what I am trying to communicate. I meant that to be an example of the depths that many language designers go to implement the language in that language. I don't mean to say that we need to stop writing Pd objects in C, python, whatever, I just think that we should try to make as much of Pd as possible implemented in Pd.
As for patcher vs. procedural/OO programming, its a very different mindset, and I think its harder to learn a patcher language if you already know procedural or OO programming. But I have recently been pushing myself to try to think in a Pd way when programming with Pd, and try to break the habit of procedural/OO programming. I had a number of minor breakthroughs where I found that when I did things the Pd way, it was actually really quick.
This reminds me of my phases of learning programming. I started with BASIC, line numbers and all, and when I started with procedural programming, it was my habit to write long, convoluted procedures. It took time to learn how to write nice, short procedures. And of course, I had similar experience in the switch from procedural to object-oriented programming.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
Good time for me to chime in.
pixelTANGO (formally pre-released as v_) in indeed a set of high-level GOP abstractions for Gem. Each module includes the UI and the functionality. Gem chains are considered "layers" starting with a header (gemhead) and ending with a footer (geo). The difference is that the separate modules are connected through two patch buses, one for Gem control data and another using pd messages for passing control data from one abstraction to another (without global S-R). The modules are PD abstractions and I've been making a real effort to make them organized and readable. pixelTANGO also has a couple UI improvements in the form of "entry" and "popup". Hopefully more to come in the future.
Property dialogs for abstractions would be very useful for high-level abstractions.
Using Frank's suggestions help patches for abstractions will be in the pixelTANGO releases.
There is an early pre-release (w/out help patches) available at:
http://www.ekran.org/ben/research/PixelTANGO-pre-release-v0.1.tgz
So far pixelTANGO has only been tested on OSX, but all externals should work fine on linux.
I think pixelTANGO would be a good thing to look at in terms of this current discussion.
pixelTANGO is part of the Open Territories project (tot.sat.qc.ca) Funded by Heritage Canada and supported by the SAT, Interaccess and others.
Ben
Hans-Christoph Steiner wrote: | | | So all of the ideas from the pd~conference are still swirling around my | head and slowly distilling out. One idea which I think emerged from the | conference about how Pd should ideally be structured: | | - high level objects for rapid programming and beginners | - high level objects would be written in Pd so that the user can easily | get inside it | - Pd should provide a broad set of the lowest level of operators, | whether they be for audio, messages, video, etc. | | One key thing for this idea to work is that objects written in Pd should | behave the same as those written in C, C++, etc. Things are already | headed in this direction, with such new features as help patches for | abstractions, etc. | | I think this idea should be broadly applied in Pd and there are already | a number of examples of this. A set of toxy widget abstractions would be | a great solution for GUI objects, and I think the video/graphics | packages already provide low level operations, it would be good to see | more high level, reusable abstractions for video/graphics. | | I am currently in the process of implementing a set of cross-platform | objects for general access to Human Interface Devices within Pd and this | idea is a central inspiration. I am implementing a HID event object then | I am making objects written in Pd for higher level access, like [mouse], | [joystick], [tablet], etc. | | That's my two bits, I'd love to hear what others think. | | .hc | | | ____________________________________________________________________________ | | | "Information wants to be free." | -Stewart Brand
On Wed, 13 Oct 2004, Hans-Christoph Steiner wrote:
- high level objects for rapid programming and beginners
- high level objects would be written in Pd so that the user can easily
get inside it
Yes, because
1. Seeing the patcher (code) behind the abstraction (class) is a good way to understanding... well, often... it's akin to (part of) the embedded class browsers of some programming environments, where you get to see the source code of a class.
2. If a class is lacking flexibility, then you can duplicate the class and add/remove/change elements in it. Sometimes you don't even need to fully understand the class to make useful changes to it.
3. Trying to follow DRY/OnceAndOnlyOnce, you want strip out unnecessary details from any piece of code, and one of the ways of doing that is using a different (higher-level) programming language. (e.g. PDP uses C/Forth/Pd; GF uses C++/Ruby/Pd)
- Pd should provide a broad set of the lowest level of operators,
whether they be for audio, messages, video, etc.
This is important because when implementing Pd classes in Pd itself you need to have enough elements to make that level of programming comfortable, and one of major reasons I've had for writing things in Ruby instead of Pd, is that although Pd is higher-level, it doesn't have enough control structures.
Being relatively new to dataflow programming, and having mostly only seen Pd, I wouldn't quite know what control structures are missing from the core... except for [demux] [range] etc from jMax... but even with that I have a hard time figuring out certain problems in Pd and I feel that it could be solved by inventing new control structures.
Maybe we need a "Design Patterns" book for Pd. ;-)
One key thing for this idea to work is that objects written in Pd should behave the same as those written in C, C++, etc. Things are already headed in this direction, with such new features as help patches for abstractions, etc.
BTW, have I asked before, how do I handle variable number of arguments in an abstraction? jMax had $* ...
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
-
B. Bogart -
cyrille henry -
d.lj -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Matju -
Tim Blechmann