That is indeed true. I suppose it wouldn't hurt to nag google, and it
might even help. But I don't think it would change this year's outcome.

I think the key to getting a grant like this is to know what they are
looking for and tailor the grant to that. It would be useful if
someone tried to find any materials from the successful projects and
report back what they learned. I tried to do that in the past.

.hc

On Mar 20, 2009, at 4:01 PM, Rich E wrote:

Of course it would be nice to do the projects regardless of funding, but in reality they just won't get the same attention to detail and thoroughness. I don't have a job except through grants like this..

I'm still all for making apython libpd module... but who knows when summer rolls around and i'm broke.

Do you think it is any good to question/complain to google about not getting accepted two years in a row? I looked at some of the other project pages and not only is the pd application just as good, I think the proposed projects are much more valuable to the open source community. I don't want to name anything in specific, but I saw some well funded projects that only proposed various bug fixes, that were accepted (literally there is a project that says "go through the bugs list and fix whatever you can).

regards, Rich

On Thu, Mar 19, 2009 at 12:08 PM, Hans-Christoph Steiner
hans@eds.org wrote:

...

So now we have a nice collection of projects sketched out from the
GSoC application, let's encourage people to take them on. If anyone
wants to get involved with Pd development, take a look at the project ideas and
if you are interested, then ask about them on the list and we can get
started.

http://puredata.info/dev/summer-of-code/GoogleSummerOfCodeIdeas2009

I think next time someone else should take on the GSoC application
process. I'm 2 for 2 at not getting it, I've never had much luck with
grants. And we have lots of well-sketched out projects. We should probably
chuck the application part and start from scratch.

.hc

---

All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Programs should be written for people to read, and only incidentally
for machines to execute.

• from Structure and Interpretation of Computer Programs

On Mon, 23 Mar 2009 13:03:55 +0000 Chris McCormick chris@mccormick.cx wrote:

Also, I hate to be cynical, but I can't see any way even remotely in which Google could use Pd to make a profit. ;)

Profit aside, you can make a fundamental partition in computing between forward looking systems (predictive, generative, hypothetical, AI, imaginative type systems) and backward looking (retrospective, analytical, indexing, organising, sort, search, existing value based systems). A bit like left and right brain faculties. Most problems involve elements of both, but Google's domain (search) really falls more into the latter, while applications of Pd are constructive and fall better into the former.

hmm.. now i would have thought that with google investing a great many resources into mobile technology, ie. their first real attempt at killing off the competition (apple) with their phone architecture (android), and with the relative success of rjdj for the (apple) iphone, they would be rushing at the opportunity to port a 'killer app' to their gadget and supporting the environment that harbours this app (pd). afterall the frivolous world of consumer gadgets requires that users have access to lovely toys that do the things which make those consumers like the gadget enough to warant spending the cash in the first place (no decent software, no gadget, no matter how 'cool', nerdy or utilitarian the thing is in the first place).

to be even more cynical, i would suggest that if the application was rewritten to suggest a focussed effort at making pd/rjdj support android and that the 'other' modifications fell under this umbrella project we may have stood a better chance. but this is all rather hypothetical and would require playing silly games with a corporate monolith.

or perhaps a company that relies so heavily on string manipulation considered pd useless? ;)

ciao dmotd

On Monday 23 March 2009 23:03:55 Chris McCormick wrote:

Yo,

IIRC, one of their complaints from last year was that our application had too many parts. Next time we should pick just one or two specific tasks and go with them. Maybe with a community vote or whatever. Also, I hate to be cynical, but I can't see any way even remotely in which Google could use Pd to make a profit. ;) Thanks for your huge effort anyway, Hans and Georg.

Best,

Chris.

On Mon, 23 Mar 2009, Chris McCormick wrote:

IIRC, one of their complaints from last year was that our application had too many parts. Next time we should pick just one or two specific tasks and go with them. Maybe with a community vote or whatever. Also, I hate to be cynical, but I can't see any way even remotely in which Google could use Pd to make a profit. ;) Thanks for your huge effort anyway, Hans and Georg.

It's not just that, it's that Pd is still relatively non-mainstream. I can imagine plenty (or even most) of programmers being allergic to Pd and thinking it's messy, difficult to program with, and generally an exercise in contorsion. I mean, what do you do with a language that has no builtin [demux] (that's called an if-else anywhere else), in which hot-vs-cold is troublesome (else [expr] wouldn't be *so* attractive), etc.; if programmers that don't use pd had a better opinion of pd, some things like this could have more of a chance. That's when supposing Google is trying to stay neutral and not selecting for profit. Else it's an ever harder game, I suppose.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Wed, 25 Mar 2009, error developer wrote:

i think it's not appropriate to compare pd to programmng languges

I believe that even if we try to refrain to compare pd to programming languages, and refrain from calling it a programming language, it still will be compared to programming languages simply because it's used in the same way that programming languages are and is in direct competition with programming languages when deciding which tools to pick to do a certain job. Teaching Pd leads to the same kind of challenges as does any other programming language if you teach Pd for what it's good for.

we do call it a languge, but it's rather more corect to call it like and visual engeneering environment whch hase a set of object or something like that,

There's nothing more correct in that, except perhaps politically correct, if that's what correctness is. That correctness is all about avoiding comparisons and doesn't lead to anything useful.

if you could at least compile them into some sort of binaries

• that would be a bit more comparable

No, there are *plenty* of languages for which there is either no compilation involved, or the compilation process is completely hidden from the user, such that you never have to deal with compilation directly. (Pd's DSP has an almost-hidden compilation step, for example.)

..and pd is not a virtual machine either

This concept of compiling a programme to a certain kind of format in which the instructions are written down in a way similar to traditional machine languages... this is only incidental to what a programming language is, it doesn't make a programming language more real or anything. It's just a strategy for achieving the goal of running the programme... or more exactly, to run it more quickly than by using more obvious ways of executing a programme (that is, an interpreter).

that leads to flae wars like between tclers and lispers ..but to me both are actually quite simpatic ;)) and i can see my self coding in both one day ..

If you know Tcl and Lisp and Perl and Ruby and Python and such, you know that the compilation aspect and the virtual machine stuff is very secondary. It's not shoved in your face like it is with C++ and Java. Yet those are true programming languages because of the degree of flexibility that they offer in solving problems. Then Pd is not much different from them... well, it is, and surely it's less flexible than those languages, but it's far above the threshold at which you start to have much more flexibility than using things that are not considered programming languages at all.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Thu, 26 Mar 2009, Jonathan Wilkes wrote:

--- On Wed, 3/25/09, Mathieu Bouchard matju@artengine.ca wrote:

...

I mean, what do you do with a language that has no builtin [demux] (that's called an if-else anywhere else)

Does [expr~ if ( $f2 == 0, $v1, 0 ); etc.] fill that role?

When processing just pd signals, a real conditional execution is done by [switch~] or [block~] and can only be applied on full subpatches. The [expr~ if] does compute both clauses of the "if", and then discards one of the results. This means that if a clause whose result gets discarded would cause an error, it will. The only difference between that and just multiplying one of the results by 0, is when one of the clauses is "infinite" or "NaN", then multiplying it by 0 won't cancel it. And then, that if() can only happen inside of [expr~]'s world, and so has no direct impact on other objects.

But I was more thinking of the message-system. In that case, [spigot] is an if-statement in which execution is really conditional: a "block of code" being a connection from an outlet to a bunch of objects that do something when you send them a message, then [spigot] decides whether something happens or not, in a generic way. [select], [route] and [moses] are special-case if-statements.

The if-else statements require a pair of [spigot]s and a [==]. This could be put in an abstraction, a total of six objects, and named demux2.pd or spigot2.pd, but no, Pd bundles absolutely no abstractions, and though the code for this very common case is just a few lines away from [spigot], Pd is still without it.

(If so, it certainly strengthens your following point.)

...

, in which hot-vs-cold is troublesome (else [expr] wouldn't be *so* attractive), etc.

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.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

On Thu, 26 Mar 2009, Frank Barknecht wrote:

A bit shorter, less effective and because of list-conversion not fully transparent, but still handy is this idiom: [list prepend 0] | [route 0 1] Send 0 and 1 to the prepend's right inlet to switch outlets. It becomes more useful with more choices.

Interesting, but I very very much expect a demuxer to be generic enough to apply uniformly to all selectors even "list". This disqualifies pretty much everything with [list] and [route] in them, as both have special cases for list-selectors that are hard to compensate for. I definitely don't want to be programming like that. When I think about getting the a message to the right place, I want to do so without having to think about the content of the message... especially for something as common as a list selector.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

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 vvvv
works. For me, I make sense of vvvv by thinking of it as Pd with only
tilde objects, no message objects.

.hc

               ¡El pueblo unido jamás será vencido!

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

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

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

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::map<int,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 that's not enough, that it's still better to make a format 99%-compatible with Pd than 0%.

It's a good point, but I don't think I'd bother making a new language compatible with Pd because it wouldn't be trying to do the same thing as Pd is used for.

As for not redo-ing things, you are right that it should be a very strong reason to start something from scratch versus using existing code.

...

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.

Yes, that's very true. I guess with the idea of a very social format like YAML or JSON I am trying to advocate a language that interoperates nicely and easily with other languages and hence isn't a small island of software, but rather a part of the archipelago with a fancy port which many ships like to dock at. Whoa, that's a bit of a metaphor stretch, sorry.

...

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.

Libraries.

Best,

Chris.

http://mccormick.cx

On Mon, Apr 6, 2009 at 8:06 PM, Mathieu Bouchard matju@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