Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

On 2010-04-19 18:56, Vilson Vieira wrote: > Guys, > > and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so > similar? no, the only similarity between the 2 is, that both run on computers (you could say "smallish computers", but compared to computers some years ago, there is no

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

Guys, and how about PD-anywhere? How ZenGarden is influenced by? Isn't them so similar? Thanks. 2010/4/18 Frank Barknecht > On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote: > > I don't think it is more ambiguous than the order of execution of this: > > > > [adc~] > > | > >

Re: [PD] Invisible wires was Re: PD] Zen Garden re-implementing the wheel in C++?

On Sat, Apr 17, 2010 at 04:50:02PM +0200, Matteo Sisti Sette wrote: > Matteo Sisti Sette escribió: > > >So my question is which of these is true: > >A) there is always a one-block latency between a s~ and a corresponding r~ > >B) there _can_ be a latency, depending on the execution order Pd > >cho

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

On Sat, Apr 17, 2010 at 04:12:51PM +0200, Matteo Sisti Sette wrote: > I don't think it is more ambiguous than the order of execution of this: > > [adc~] > | > [dac~] > > Either (a) adc-dac or (b) dac-adc. In Pd it's always (a) because patch cords define the execution order for signals. There's

Re: [PD] Zen Garden re-implementing the wheel in C++?

On Sat, 17 Apr 2010, Spencer Russell wrote: Agreed that Pd's code is certainly organized in an object-oriented way, and the architecture that Miller has constructed to do OOP in C is extremely clever Well, not that clever. This kind of design has been implemented quite a number of times by v

[PD] Invisible wires was Re: PD] Zen Garden re-implementing the wheel in C++?

Matteo Sisti Sette escribió: So my question is which of these is true: A) there is always a one-block latency between a s~ and a corresponding r~ B) there _can_ be a latency, depending on the execution order Pd choses, and you can't know whether there will or won't be. C) there _can_ be a laten

Re: [PD] Zen Garden re-implementing the wheel in C++?

On Sat, Apr 17, 2010 at 1:38 AM, Mathieu Bouchard wrote: > On Fri, 16 Apr 2010, Spencer Russell wrote: > >> I'm excited about the idea of a more object-oriented approach, > > Pd's implementation was made with an object-oriented approach. You can't get > much more object-oriented than that. If you

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

> > |adc~| > > | > > |send~ foo| > > > > |receive~ foo| > > | > > |dac~| > > > > it execution order is ambiguous. > > > > either (a) adc-send-receive-dac or > > (b) receive-dac-adc-send. > > the case (b) introduces one sample block of latency between > > send and receive, (a) doesn't

Re: [PD] Zen Garden re-implementing the wheel in C++?

> unfortunately, this is not a trivial issue. > > dynamically changing the signal graph is possible (actually, i had an > implementation of that in nova). do the topological sorting in the > background and you are fine. > > the tricky part are implicit dependencies. see this trivial patch: > |adc~|

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

> |adc~| > | > |send~ foo| > > |receive~ foo| > | > |dac~| > > it execution order is ambiguous. > > either (a) adc-send-receive-dac or > (b) receive-dac-adc-send. > the case (b) introduces one sample block of latency between > send and receive, (a) doesn't introduce any latency. I don't think it

Re: [PD] Zen Garden re-implementing the wheel in C++?

> Giving up extensible generality and moving > from a linear structure to finite but > 'big enough' adjacency matrix always > seemed the way to go. it is not really a problem of the graph representation, but it is about what i call `implicit dependency'. in order to traverse a graph, you can trav

Re: [PD] Zen Garden re-implementing the wheel in C++?

That would have been the function of a versatile [z~] object in my mind. Default would be [z~ -1] or a one sample delay, and a second inlet would allow [z~ -blocksize] to do what we normally do with a [s~] and [r~]. There was one from Zexy that I used for a long time time before I understood how

Re: [PD] Zen Garden re-implementing the wheel in C++?

> I've actually wondered this for a while: Why is it that send~ and > receive~ objects require special treatment instead of being treated > the same as any other edge in the graph? I understand that in the > current implementation using s~ / r~ pairs is the only way to create a > graph with cycles

Re: [PD] Zen Garden re-implementing the wheel in C++?

Giving up extensible generality and moving from a linear structure to finite but 'big enough' adjacency matrix always seemed the way to go. I'm not speaking for Martin on ZenGarden though, I'm not sure what his current ideas are, or even if its still active. How did topoloical sorting of a lis

Re: [PD] Zen Garden re-implementing the wheel in C++?

On Sat, Apr 17, 2010 at 9:04 AM, Tim Blechmann wrote: > unfortunately, this is not a trivial issue. > > dynamically changing the signal graph is possible (actually, i had an > implementation of that in nova). do the topological sorting in the > background and you are fine. > > the tricky part are

Re: [PD] PD] Zen Garden re-implementing the wheel in C++?

> depending on their implementation, it may be possible to do > click-free changes of the dsp graph, which is the weakest part > of the dsp engine of pd. This recalls me of a possibly unrelated even "bigger" problem: you get audio dropouts even by opening a window (such as a subpatch or abstrac

Re: [PD] Zen Garden re-implementing the wheel in C++?

unfortunately, this is not a trivial issue. dynamically changing the signal graph is possible (actually, i had an implementation of that in nova). do the topological sorting in the background and you are fine. the tricky part are implicit dependencies. see this trivial patch: |adc~| | |send~ fo

Re: [PD] Zen Garden re-implementing the wheel in C++?

I think that using [throw~]/[catch~] and [s~]/[r~] can do the job really ..i'm not sure what are you trying to archieve but i hope you get my idea .. also, can someone tell if sending or throwing signals adds any processing overhead? On Sat, Apr 17, 2010 at 11:24:14AM +0100, Andy Farnell wrote: >

Re: [PD] Zen Garden re-implementing the wheel in C++?

Yes. This was a design goal from early on. A dynamically rewritable signal graph is quite essential to advanced procedural audio. On Sat, 17 Apr 2010 12:04:09 +0200 Tim Blechmann wrote: > > I'm excited about the idea of a more object-oriented approach, and > > especially with the idea of ditchi

Re: [PD] Zen Garden re-implementing the wheel in C++?

> I'm excited about the idea of a more object-oriented approach, and > especially with the idea of ditching all the Tk/Tcl garbage, but I > don't really see the utility of re-implementing all the DSP graph > code. depending on their implementation, it may be possible to do click-free changes of t

Re: [PD] Zen Garden re-implementing the wheel in C++?

On Fri, 16 Apr 2010, Spencer Russell wrote: I'm excited about the idea of a more object-oriented approach, Pd's implementation was made with an object-oriented approach. You can't get much more object-oriented than that. If you mean that the object-oriented approach has been implemented usin

Re: [PD] Zen Garden re-implementing the wheel in C++?

I apoligize for the perhaps poor choice of words. I wasn't bashing tcl in general, but only meant that there seems to be a fairly large sentiment that it doesn't belong in the interface between client and server processes. -s On Apr 16, 2010 9:02 PM, errordevelo...@gmail.com

[PD] Zen Garden re-implementing the wheel in C++?

Hey List. Just came across Zen Garden: http://wiki.github.com/mhroth/ZenGarden/ Seems like the RJDJ crew is re-implementing PD in C++, in it's full object-oriented glory. I'm excited about the idea of a more object-oriented approach, and especially with the idea of ditching all the Tk/Tcl garba