[PD-dev] an idea for Pd structure

[d.lj]

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 at iem.at
 |> > http://iem.at/cgi-bin/mailman/listinfo/pd-dev
 |> >
 |>
 |>
 |>
 |> _______________________________________________
 |> PD-dev mailing list
 |> PD-dev at iem.at
 |> http://iem.at/cgi-bin/mailman/listinfo/pd-dev
 |>
 |
 |
 |_______________________________________________
 |PD-dev mailing list
 |PD-dev at iem.at
 |http://iem.at/cgi-bin/mailman/listinfo/pd-dev
 |

-- 
>          <          d          u          .          o          7          G
GPG-key at http://xdv.org/~jdl/jdl.pub.asc