2009/4/9 Rich E
>
>
>
> 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 documenta
On Mon, Apr 6, 2009 at 8:06 PM, Mathieu Bouchard 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 w
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,
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 w
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?
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
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 inle
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
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
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 the
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 r
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 [+] [-
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 so
13 matches
Mail list logo
