Hi Sébastien,

On 03/06/2012 03:04 PM, s p wrote:

I was wondering, what's the status of the project ?

Although I am often thinking about it, the project is effectively on hiatus since I had a kid and moved on to other projects like PdDroidParty and relaxing infront of the TV with a beer.

What are your plans?

My plan is to continue to merge patches from people who submit them. :)

Because there are many more changes and optimizations I'd like to make. Mostly some Javascript stuff : better use of prototype for saving memory, splitting the big fat file in several (probably using require.js, or something like that), writing real unittests (probably using QUnit) and then I can get a CI server to run them.

Sounds great!

In terms of splitting the big fat file, my preference would be for there to be an option to download a monolithic pd.js to make the end-user's life easier. This could easily be accomplished by a script on the download section of the webpd website or by a Makefile in the project. If you go ahead and split the file I am happy to take care of a way of putting it back together again for the user. I would prefer not to use a dependency on the client side.

Really the best thing would be if it worked like processing.js where the user can include a single JS file and then party time.

Well, basically, I'm very motivated to push this project forward. So how should we handle that ? Are you still active ? Would you like to give me admin rights on the github repo, or should I just fork (as a different project) to go my way ?

Great to hear somebody motivated wants to work on this.

I would love to remain active in so far as maintaining, and creating a proper website for the project and to continue to merge patches into my branch, and also maybe to help with architecture issues as they arise. I think the best way forward is if you fork and go for it, and issue pull requests, or if that's too much of a hassle I can watch your fork and merge things as you do them.

This is already how I have been working with the great patches from Brandon and Spencer over the last couple of years. They each moved the project forward nicely with a whole bunch of objects and changes.

The webpd site really needs a makeover and I can commit to doing that and general maintenance tasks on the project.

In terms of what needs doing in pd.js itself, I think the following are the most important (this is a general summary of TODO.txt with some other stuff I just thought of):

• Architecture issue - connection fanning should be supported

(connecting multiple wires to a single audio inlet). This means that inlet and outlet data structures should become an array instead of a pointer to a single object.

• fix [random] and [noise~] to use Pd's exact algorithm.

• pd.receive() callback registration which should work a bit like

libpd's - a [send x] in Pd should be caught with: pd.receive("x", function(msg) { console.log(msg); });.

• Add an AudioDriver entry for Chromium browser. There is a new audio

API in Chromium to use for that. This would give us major browser coverage.

• More testing of the flash AudioDriver fallback. This is reported to

work in Safari but I would also like to make sure it works in Internet Explorer. I had been trying to support ie6 and forwards but maybe I am being a little too conservative on that and ie8 is probably sufficient in the modern internet. But hell, if it works on ie6 too we win at internet.

• Architecture issue - abstractions and subpatches should work. At the

moment only a single patch can be run at a time. This one is probably difficult, but maybe not so much if you modularize things out into separate files.

• Lots more unit tests!

In general my philosophy with WebPd is to try to get everything as [sample] accurate and close as possible to the behaviour of real Pd. That way a user can rely on their patches running in the same way online after authoring them in Pd.

My other philosophy is to have it run with as few dependencies as possible. For example, it should not depend upon jQuery or prototype.js or anything like that. It's not so hard to re-implement things like Ajax GET as you can see from the code. Core Pd itself has very few dependencies and I really like that about it. It helps a lot with portability. Which is another thing - the more browsers this runs on, the better!

At the end of the day I guess it's kind of obvious that if there was a way to make a patch in Pd and then put that patch on a website for as many people as possible to play with, we all win. So all of the above is just detail if you share that same basic vision.

Go nuts!

Cheers,

Chris.