Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Apr 6, 2009 at 8:06 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Mon, 6 Apr 2009, Chris McCormick wrote: No, that's not at all the reason I think that a format like JSON or YAML would be useful. It's more to do with patches being more widely and easily parseable, mashable, etc. It's to do with interoperating with more programs than just Pd itself. Sure, we could do this and that, and we could use 'a bit of imagination' but the current format of Pd patches is not friendly or popular. I'd rather have a patch format that plays nice with other programs and is easily human readable. Ok, you know what playing nice means and what human readable means, I can't help you with that at all. I didn't watch the infomercials about JSON, so I don't know how amazingly easier than everything else it is. I sometimes would like to write a part of a patch in python, like say all the audio files in one directory, each in a seperate array, and then load it in pd. This can be done completely in pd, but for reasons I don't yet understand (other than it is quite easy to crash pd when dynamic patching), it is not widely supported. Writing this patch in python with the current format would just be messy. Doing it in JSON or YAML would be straightforward. Maybe, as more of a proof of concept, a JSON-pd format file converter can be made? regards, Rich How many parsers are there which read Pd patches? One mainly, maybe other obscure ones which I don't know about, and some that I have written which nobody knows about. How many parsers are there for the JSON format? Hundreds, in hundreds of different languages. After the parser is ready, you still have to write the programme that will actually do something useful with the patch that has been read and parsed, and that will most likely the part of the work that will be the most significant, especially if you don't bother about handling backslashed spaces properly, because pd doesn't anyway. If you already have a [netreceive] in the target language, you already have a parser for much of the pd format... Yep, I get what you are saying, but you are unfortunately wrong. Nobody cares about Pd's syntax except our small band of merry Pd people. So why would those people who don't care about Pd's syntax would ever care about processing Pd patches? It just doesn't make any sense. Even your point about not knowing how JSON (or YAML or whatever) is going to be used is irrelevant because of the gain in interoperability with other programs and people. I don't think any interoperability is going to be gained from using a JSON-based format (that you still haven't specified) because no non-Pd people will want to process patches. Forget everything about the format being readable by real human beings (by opposition to those damn pd users), a JSON-based patch format will only achieve one thing, allow the JSON fans to say that Pd supports JSON. Yes, that's very true. I guess with the idea of a very social format like YAML or JSON Once you consider the actual number of XML/YAML/JSON users who would be processing any pd patch if it were coded in their favourite encoding, then you wouldn't feel nearly as lonely with the Pd format, really. I'm expecting you to be disappointed by what JSON will bring to Pd. In any case, it's still easy to make a Pd-to-JSON converter, so, invent yourself a suitable JSON-subformat for converting your Pd patches to, and see whether any JSON user cares, and it will save us having to convert all of our patches to JSON, really. I am trying to advocate a language that interoperates nicely and easily with other languages and hence isn't a small island of software Be careful of all of the details of the software, which is everything else that isn't already covered by JSON, which is almost everything of what makes a patch a patch and what makes pd pd (or what makes some other patching system be what it is). The superficial part of the syntax is superficial but it's easy to exaggerate it at the expense of all of the depth of the syntax. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
2009/4/9 Rich E reakina...@gmail.com Writing this patch in python with the current format would just be messy. Doing it in JSON or YAML would be straightforward. Maybe, as more of a proof of concept, a JSON-pd format file converter can be made? Could be done for a customized CMS for web documentation, something made with some python parsers and a MVC web framework like Django... (Ruby fans will say Ruby on Rails, but you got the idea)... This could be a good reason to think about a Puredata_abstraction to JSONparser, as was discussed in other thread (Pdpedia and random generation )... Since JSON can be parsed even to a RSS format easily... See that? Read new patches docs at the RSS news? Than also the string issues could be solved editing .pd documentation in text based editors. And even some web based WSIWYG editor that would generate pd readable documentation :) Could be? té+ glerm ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Tue, Mar 31, 2009 at 10:27:07PM -0400, Mathieu Bouchard wrote:
On Tue, 31 Mar 2009, Chris McCormick wrote:
Then I'd like the DSP stuff not to be a special case, but rather a
library you can import.
It's not much of a feature. It might be a sign of a more modular design,
but what would actually you do with Pd that'd require DSP to be separated
like that?
Maybe similar things to what you can do with pipes on the unix command line.
Except times ten.
Next I would like it if the graphs were represented by a data structure
that doesn't suck (e.g. an associative array not a textfile) so that it
would be possible to pass the network definition (e.g. the patch)
itself through another network to dynamically create and modify
patches. This new representation of a patch should be serialisable as
JSON or similar
This makes no sense to me. a JSON serialisation is already a textfile,
and the .pd file format is already a serialisation of some data
structure. Actually, that data structure may suck, but it's very
replaceable by some other structure, but that doesn't affect the file
format. I have made a version of Pd that replaces linked-lists by
something I called t_boxes which is defined using a C++ associative array
structure:
struct t_boxes : t_gobj {std::mapint,t_gobj * map;}
Way cool.
But really, the file format is the same. I had planned a new file format
but it was 99% compatible with Pd. I don't believe that we'd have to
switch to JSON just before it's newer.
If you're complaining about the format of the IEMGUI constructors, that's
a different problem. This is not part of the .pd format by itself: it's a
subformat. You can abuse another format in the same way, be it JSON, XML,
YAML, LISP data, TCL data, other text formats, binary formats.
The way that IEMGUIs are saved could be fixed without having to change
the Pd format, really. It just needs a bit of imagination. And then, the
only code you'd need to change would be the code of IEMGUIs, just as if
they were still externals. For example, IEMGUIs could save themselves
using Flext-like attributes or GridFlow-like comma-messages, which are
two styles of named-arguments in use in Pd (the latter is actually more
like a [initbang] with a messagebox).
No, that's not at all the reason I think that a format like JSON or YAML would
be useful. It's more to do with patches being more widely and easily parseable,
mashable, etc. It's to do with interoperating with more programs than just Pd
itself. Sure, we could do this and that, and we could use 'a bit of
imagination' but the current format of Pd patches is not friendly or popular.
I'd rather have a patch format that plays nice with other programs and is
easily human readable.
so that it's easy to modify by hand and to parse, and to save to disk,
or send across a network.
Well, you'd have to explain how JSON is going to be any easier to modify,
parse, save and send, because I don't see it.
How many parsers are there which read Pd patches? One mainly, maybe other
obscure ones which I don't know about, and some that I have written which
nobody knows about. How many parsers are there for the JSON format? Hundreds,
in hundreds of different languages.
Especially because when you
say JSON, there's nothing that tells me exactly how JSON is going to be
used for that. In any case, the differences between the many ways that
you can use JSON for that, parallel the differences between the many ways
Pd's syntax could be used.
Yep, I get what you are saying, but you are unfortunately wrong. Nobody cares
about Pd's syntax except our small band of merry Pd people. Even your point
about not knowing how JSON (or YAML or whatever) is going to be used is
irrelevant because of the gain in interoperability with other programs and
people. The details of how Pd patches are represented in a new format are not
as important as the idea of using a popular, human friendly, and widely
parseable format to represent them.
JSON would be nice as it's supported by web frameworks, whcih means you
could do super-cool stuff like websites
Maybe it's just me... I'm not especially web-centric... well, I use the
web a lot, but haven't done any serious web development in this
millenium... so far.
I'm very conservative when it comes to web2.0 and that kind of hype, but I am a
big fan of standards and interoperability.
I've thought many times about starting to code this language, and have
actually hesitantly started a couple of times, but very quickly I
realise what a massive undertaking it is and stop.
Well, every person has their favourite way or dream way to encode data,
but it doesn't mean it's enough of a reason to redo things. When I
thought about all those things about format modifications I considered
that it's easier to go in the direction of the grain, that is, to use
the same parser that is already used all over Pd, and if
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, 6 Apr 2009, Chris McCormick wrote: No, that's not at all the reason I think that a format like JSON or YAML would be useful. It's more to do with patches being more widely and easily parseable, mashable, etc. It's to do with interoperating with more programs than just Pd itself. Sure, we could do this and that, and we could use 'a bit of imagination' but the current format of Pd patches is not friendly or popular. I'd rather have a patch format that plays nice with other programs and is easily human readable. Ok, you know what playing nice means and what human readable means, I can't help you with that at all. I didn't watch the infomercials about JSON, so I don't know how amazingly easier than everything else it is. How many parsers are there which read Pd patches? One mainly, maybe other obscure ones which I don't know about, and some that I have written which nobody knows about. How many parsers are there for the JSON format? Hundreds, in hundreds of different languages. After the parser is ready, you still have to write the programme that will actually do something useful with the patch that has been read and parsed, and that will most likely the part of the work that will be the most significant, especially if you don't bother about handling backslashed spaces properly, because pd doesn't anyway. If you already have a [netreceive] in the target language, you already have a parser for much of the pd format... Yep, I get what you are saying, but you are unfortunately wrong. Nobody cares about Pd's syntax except our small band of merry Pd people. So why would those people who don't care about Pd's syntax would ever care about processing Pd patches? It just doesn't make any sense. Even your point about not knowing how JSON (or YAML or whatever) is going to be used is irrelevant because of the gain in interoperability with other programs and people. I don't think any interoperability is going to be gained from using a JSON-based format (that you still haven't specified) because no non-Pd people will want to process patches. Forget everything about the format being readable by real human beings (by opposition to those damn pd users), a JSON-based patch format will only achieve one thing, allow the JSON fans to say that Pd supports JSON. Yes, that's very true. I guess with the idea of a very social format like YAML or JSON Once you consider the actual number of XML/YAML/JSON users who would be processing any pd patch if it were coded in their favourite encoding, then you wouldn't feel nearly as lonely with the Pd format, really. I'm expecting you to be disappointed by what JSON will bring to Pd. In any case, it's still easy to make a Pd-to-JSON converter, so, invent yourself a suitable JSON-subformat for converting your Pd patches to, and see whether any JSON user cares, and it will save us having to convert all of our patches to JSON, really. I am trying to advocate a language that interoperates nicely and easily with other languages and hence isn't a small island of software Be careful of all of the details of the software, which is everything else that isn't already covered by JSON, which is almost everything of what makes a patch a patch and what makes pd pd (or what makes some other patching system be what it is). The superficial part of the syntax is superficial but it's easy to exaggerate it at the expense of all of the depth of the syntax. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Mar 30, 2009 at 11:28:40AM -0400, Mathieu Bouchard wrote: On Sat, 28 Mar 2009, Chris McCormick wrote: When I was thinking about writing a general purpose dataflow programming language which addresses some of Pd's shortcomings, I did a lot of thinking about the hot and cold inlet paradigm. What I came up with was the following [snip] conditions are met: * Every cold inlet has been pinged (receives data) * Any hot inlet has been pinged (receives data) * Inlets cache their last received data if no new data arrives. In Pd, DSP inlets act like the 'cold' inlets above Well, perhaps you should rename 'neutral' inlets to 'cold' and find another name for what you call 'cold'. Even then, DSP inlets still don't work like your 'cold' inlets because of how they combine together a fan-in (several wires to one inlet) and because of how they handle a non-connected inlet. Ah yes. In this hypothetical dataflow language in my head, whenever you try and fan cables either in or out, the patcher would automatically turn the fan into a sort of 'bus' of connections like Pd's [t] object. In other words, in this language it would not be possible to fan connections. A default behaviour for incoming fans would be to sum inputs (like DSP fans do now), but this would be easily configurable to 'replace' instead of 'add' as current message in-fanning does. Hmm, maybe I haven't thought that through enough. I like the idea of this behaviour being defined by the class author, but (re)configurable by the user. Then this would need a special 'run' method to be defined in t_class, preferably outside of the normal method-list. At first thought I think I'm in favour of reconfigurable inlets, but I'd like to see a proof-of-concept first. I don't think all the features I'd like in a general purpose dataflow language can even be added to Pd without serious mangling. For a start I'd like the basic data types that all modern languages support like associative arrays, strings, etc. Then I'd like the DSP stuff not to be a special case, but rather a library you can import. Next I would like it if the graphs were represented by a data structure that doesn't suck (e.g. an associative array not a textfile) so that it would be possible to pass the network definition (e.g. the patch) itself through another network to dynamically create and modify patches. This new representation of a patch should be serialisable as JSON or similar so that it's easy to modify by hand and to parse, and to save to disk, or send across a network. JSON would be nice as it's supported by web frameworks, whcih means you could do super-cool stuff like websites which read/write/modify/run patches in your browser, or build patches that use a website to share data between multiple connected clients. Netpd would be really nice in this new language. Lastly, it should feature multi-processing out of the box. Not asking for much, am I? :) I've thought many times about starting to code this language, and have actually hesitantly started a couple of times, but very quickly I realise what a massive undertaking it is and stop. I have too much other work. I guess it would be possible to build the kernel of the lgnaguage with no GUI quite easily, but the hard bit would be the 'batteries included'. Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, Mar 30, 2009 at 06:36:04PM +0100, Claude Heiland-Allen wrote: Mathieu Bouchard wrote: At first thought I think I'm in favour of reconfigurable inlets, but I'd like to see a proof-of-concept first. IIRC the [lexpr] pdlua example has reconfigurable hot/cold inlets, but that's implemented by hand. Not sure I like the idea of a run method, what if there's more than one reasonable run action? In Pd terms that means a different action is taken depending on the input, such as float, list, specific symbol, right? So in this hypothetical language the run method could written to do something different depending on the datatype or content of the incoming data, just like it is in Pd. Or maybe I missed your exact meaning? Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Tue, 31 Mar 2009, Chris McCormick wrote:
Then I'd like the DSP stuff not to be a special case, but rather a
library you can import.
It's not much of a feature. It might be a sign of a more modular design,
but what would actually you do with Pd that'd require DSP to be separated
like that?
Next I would like it if the graphs were represented by a data structure
that doesn't suck (e.g. an associative array not a textfile) so that it
would be possible to pass the network definition (e.g. the patch) itself
through another network to dynamically create and modify patches. This
new representation of a patch should be serialisable as JSON or similar
This makes no sense to me. a JSON serialisation is already a textfile, and
the .pd file format is already a serialisation of some data structure.
Actually, that data structure may suck, but it's very replaceable by some
other structure, but that doesn't affect the file format. I have made a
version of Pd that replaces linked-lists by something I called t_boxes
which is defined using a C++ associative array structure:
struct t_boxes : t_gobj {std::mapint,t_gobj * map;}
But really, the file format is the same. I had planned a new file format
but it was 99% compatible with Pd. I don't believe that we'd have to
switch to JSON just before it's newer.
If you're complaining about the format of the IEMGUI constructors, that's
a different problem. This is not part of the .pd format by itself: it's a
subformat. You can abuse another format in the same way, be it JSON, XML,
YAML, LISP data, TCL data, other text formats, binary formats.
The way that IEMGUIs are saved could be fixed without having to change the
Pd format, really. It just needs a bit of imagination. And then, the only
code you'd need to change would be the code of IEMGUIs, just as if they
were still externals. For example, IEMGUIs could save themselves using
Flext-like attributes or GridFlow-like comma-messages, which are two
styles of named-arguments in use in Pd (the latter is actually more like a
[initbang] with a messagebox).
so that it's easy to modify by hand and to parse, and to save to disk,
or send across a network.
Well, you'd have to explain how JSON is going to be any easier to modify,
parse, save and send, because I don't see it. Especially because when you
say JSON, there's nothing that tells me exactly how JSON is going to be
used for that. In any case, the differences between the many ways that you
can use JSON for that, parallel the differences between the many ways Pd's
syntax could be used.
JSON would be nice as it's supported by web frameworks, whcih means you
could do super-cool stuff like websites
Maybe it's just me... I'm not especially web-centric... well, I use the
web a lot, but haven't done any serious web development in this
millenium... so far.
I've thought many times about starting to code this language, and have
actually hesitantly started a couple of times, but very quickly I
realise what a massive undertaking it is and stop.
Well, every person has their favourite way or dream way to encode data,
but it doesn't mean it's enough of a reason to redo things. When I thought
about all those things about format modifications I considered that it's
easier to go in the direction of the grain, that is, to use the same
parser that is already used all over Pd, and if that's not enough, that
it's still better to make a format 99%-compatible with Pd than 0%.
I have too much other work.
It's also that even if it were not too much work or if you didn't have too
much other work, if you build yourself a small island of software, you are
pretty much alone. You need as many forms of compatibility as you can.
There are several other visual dataflow programming languages that haven't
really taken off because presumably there are not enough plugins for them
and such... a not-so-well-designed programme that is very much used ends
up being much more useful than a lonely programme.
I guess it would be possible to build the kernel of the lgnaguage with
no GUI quite easily, but the hard bit would be the 'batteries included'.
I have no idea what part of the programme is the batteries supposed to
represent.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Sat, 28 Mar 2009, Chris McCormick wrote: When I was thinking about writing a general purpose dataflow programming language which addresses some of Pd's shortcomings, I did a lot of thinking about the hot and cold inlet paradigm. What I came up with was the following scheme: * Hot inlets are red * Cold inlets are blue * Neutral inlets are grey * A class has a default hot/cold/neutral inlet configuration defined by the author. * The UI allows the user to change the hot/cold/neutral status of inlets. * An instance's 'run' method is executed when any of the following conditions Well, it would be cool to have a way to configure that in Pd using a uniform syntax all over Pd, or using Pd's GUI. Even without that, I think that it would be important to introduce the run concept anyway, because it could help structuring the documentation; I mean it could be introduced at the documentation level first. For implementation, it's currently harder, especially in GridFlow where the implementation currently uses the hot/cold asymmetry to optimise. * A class has a default hot/cold/neutral inlet configuration defined by the author. * The UI allows the user to change the hot/cold/neutral status of inlets. * An instance's 'run' method is executed when any of the following conditions are met: * Every cold inlet has been pinged (receives data) * Any hot inlet has been pinged (receives data) * Inlets cache their last received data if no new data arrives. In Pd, DSP inlets act like the 'cold' inlets above Well, perhaps you should rename 'neutral' inlets to 'cold' and find another name for what you call 'cold'. Even then, DSP inlets still don't work like your 'cold' inlets because of how they combine together a fan-in (several wires to one inlet) and because of how they handle a non-connected inlet. I like the idea of this behaviour being defined by the class author, but (re)configurable by the user. Then this would need a special 'run' method to be defined in t_class, preferably outside of the normal method-list. At first thought I think I'm in favour of reconfigurable inlets, but I'd like to see a proof-of-concept first. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec 5B___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
Mathieu Bouchard wrote: At first thought I think I'm in favour of reconfigurable inlets, but I'd like to see a proof-of-concept first. IIRC the [lexpr] pdlua example has reconfigurable hot/cold inlets, but that's implemented by hand. Not sure I like the idea of a run method, what if there's more than one reasonable run action? Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mon, 30 Mar 2009, Claude Heiland-Allen wrote: Not sure I like the idea of a run method, what if there's more than one reasonable run action? When inlets are called hot and cold, it's always because there is only one thing you can call the run-action in an ordinary object: the thing that is done by sending a value in the first inlet, and the thing that is not done by the set method of the first inlet, nor by sending a value in any other inlet. But if any other inlet could be hot, then there would be a need to have a set method anywhere. And then bang and set are considered as lists by [list]. I wonder whether anything can be done to improve Pd about it without opening a can of worms or two. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Sun, 29 Mar 2009, Hans-Christoph Steiner wrote: On Mar 28, 2009, at 5:32 AM, Chris McCormick wrote: I like the idea of this behaviour being defined by the class author, but (re)configurable by the user. Sounds like an interesting idea, its something more like how works. For me, I make sense of by thinking of it as Pd with only tilde objects, no message objects. He doesn't mean to have everything work like the DSP. In that case there wouldn't be hot inlets nor cold inlets and so you wouldn't need them to be reconfigurable. He's talking about making them configurable. If you make everything work like the DSP (that is, one message per block, or one message per sample, whichever), then there are quite a few things you can't do anymore or have to do in different ways: can't avoid sending a message during a tick, and can't send more than one message during a tick, and can't recurse in any way, even to a cold inlet (you can't sum the values in a signal using just [+~] connected to itself...). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Re: DIY GSoC: getting those projects done
On Mar 28, 2009, at 5:32 AM, Chris McCormick wrote: On Thu, Mar 26, 2009 at 10:42:25AM -0400, Mathieu Bouchard wrote: No, this was about how [expr] can be a replacement for even a small network of objects. If you make an abstraction that does ($f1-$f2)*($f5-$f4)/($f3-$f2)+$f4, with just [+] [-] [*] [/] for example, then if you change some things in the cold inlets, the changes might not propagate to the bottom. This means you have to add a [pack 0 0 0 0 0] of the whole thing and [unpack 0 0 0 0 0] to ensure every hot-inlet is retriggered in the proper order. Actually, in this pack/unpack dance, maybe you can skip the hot-inlet of the abstraction (?), but apart from that, you're pretty stuck using pack/unpack if you want life to be simple. Else you can weave a mess of [t b f] objects like a spider on caffeine. That's what I mean. When I was thinking about writing a general purpose dataflow programming language which addresses some of Pd's shortcomings, I did a lot of thinking about the hot and cold inlet paradigm. What I came up with was the following scheme: * Hot inlets are red * Cold inlets are blue * Neutral inlets are grey * A class has a default hot/cold/neutral inlet configuration defined by the author. * The UI allows the user to change the hot/cold/neutral status of inlets. * An instance's 'run' method is executed when any of the following conditions are met: * Every cold inlet has been pinged (receives data) * Any hot inlet has been pinged (receives data) * Inlets cache their last received data if no new data arrives. In Pd, DSP inlets act like the 'cold' inlets above, message inlets which aren't the leftmost message inlet [usually] act like 'neutral' inlets above, and the leftmost inlet [usually] acts like 'hot' inlets above. I like the idea of this behaviour being defined by the class author, but (re)configurable by the user. Sounds like an interesting idea, its something more like how works. For me, I make sense of by thinking of it as Pd with only tilde objects, no message objects. .hc ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [OT] Re: DIY GSoC: getting those projects done
On Thu, Mar 26, 2009 at 10:42:25AM -0400, Mathieu Bouchard wrote: No, this was about how [expr] can be a replacement for even a small network of objects. If you make an abstraction that does ($f1-$f2)*($f5-$f4)/($f3-$f2)+$f4, with just [+] [-] [*] [/] for example, then if you change some things in the cold inlets, the changes might not propagate to the bottom. This means you have to add a [pack 0 0 0 0 0] of the whole thing and [unpack 0 0 0 0 0] to ensure every hot-inlet is retriggered in the proper order. Actually, in this pack/unpack dance, maybe you can skip the hot-inlet of the abstraction (?), but apart from that, you're pretty stuck using pack/unpack if you want life to be simple. Else you can weave a mess of [t b f] objects like a spider on caffeine. That's what I mean. When I was thinking about writing a general purpose dataflow programming language which addresses some of Pd's shortcomings, I did a lot of thinking about the hot and cold inlet paradigm. What I came up with was the following scheme: * Hot inlets are red * Cold inlets are blue * Neutral inlets are grey * A class has a default hot/cold/neutral inlet configuration defined by the author. * The UI allows the user to change the hot/cold/neutral status of inlets. * An instance's 'run' method is executed when any of the following conditions are met: * Every cold inlet has been pinged (receives data) * Any hot inlet has been pinged (receives data) * Inlets cache their last received data if no new data arrives. In Pd, DSP inlets act like the 'cold' inlets above, message inlets which aren't the leftmost message inlet [usually] act like 'neutral' inlets above, and the leftmost inlet [usually] acts like 'hot' inlets above. I like the idea of this behaviour being defined by the class author, but (re)configurable by the user. Best, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
