[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