[PD] WebPd - Need a small clarification

Chris McCormick chris at mccormick.cx
Tue Mar 6 08:45:41 CET 2012


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.

-- 
http://mccormick.cx/



More information about the Pd-list mailing list