Re: WebPd - Need a small clarification
Chris McCormick
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.
Chris McCormick
> Staying with your github repo as master (in
> which case it would be good to have admin rights) ? Creating a new repo
> ? Because that would be cool to have on repo that people can trustfully
> get the last version from.
Yep, gotcha. Why don't we try it with a fork and my merging pull
requests. If that turns out to be too slow/annoying I am happy to give
you commit rights. Or if you are really moving the project forward and I
am holding things back you can become maintainer to do what you like. :)
sebastien piquemal
> my preference would be for there to be an option to download a monolithic pd.js
> creating a proper website for the project
> My other philosophy is to have it run with as few dependencies as possible
function PdObject() {
this.tofloat = function(data) {
//bla
};
};
You basically give a copy of "tofloat" function to each instance of PdObject. The proper way to do that would be to use prototype :
function PdObject() {
// bla
};
PdObject.prototype.tofloat = function(data) {
//bla
};
That way, all instances of PdObject share the same method (same can be done for all methods to save a bit of memory). By using prototype, you can also implement a nice inheritance mechanism, which would make writing new objects a bit simpler.
> 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
About all the TODOs, there's definitely a lot to do !!! I understood most of them, but some are a bit unclear ... I have my own favorites - like a driver for Webkit browsers -, and some that I already know I won't do - like flash stuff : berk ... let's look towards the future for Pete's sake !!! IE will hopefully end-up implementing an audio API as well !!!
> Go nuts!
I will :)
Cheers,
Sébastien
Le mardi 6 mars 2012 09:45:41 UTC+2, Chris McCormick a écrit :
Hi S�bastien,
Le mardi 6 mars 2012 09:45:41 UTC+2, Chris McCormick a écrit :
Hi S�bastien,
Le mardi 6 mars 2012 09:45:41 UTC+2, Chris McCormick a écrit :
Hi S�bastien,
Le mardi 6 mars 2012 09:45:41 UTC+2, Chris McCormick a écrit :
Hi S�bastien,
sebastien piquemal
Chris McCormick
> > my preference would be for there to be an option to download a
> monolithic pd.js
>
> This goes without saying !!! That's actually what a CI server is meant
> for : automating builds. Basically, the split files would be only
> development files.
Cool!
> > My other philosophy is to have it run with as few dependencies as
> possible
>
> That also goes without saying ! When I talked about "prototype", I was
> not at all talking about "prototype.js", I was talking about object's
> prototype. When you do like this :
>
> function PdObject() {
> this.tofloat = function(data) {
> //bla
> };
> };
>
> You basically give a copy of "tofloat" function to each instance of
> PdObject. The proper way to do that would be to use prototype :
>
> function PdObject() {
> // bla
> };
> PdObject.prototype.tofloat = function(data) {
> //bla
> };
>
> That way, all instances of PdObject share the same method (same can be
> done for all methods to save a bit of memory). By using prototype, you
> can also implement a nice inheritance mechanism, which would make
> writing new objects a bit simpler.
Yep, that's much 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
>
> Yep !!! I definitely share that vision ! Anyways there's not other
> solution currently, since you need to prototype your patch with
> PureData, before porting it to web.
>
> About all the TODOs, there's definitely a lot to do !!! I understood
> most of them, but some are a bit unclear ... I have my own favorites -
> like a driver for Webkit browsers -, and some that I already know I
> won't do - like flash stuff : berk ... let's look towards the future for
> Pete's sake !!! IE will hopefully end-up implementing an audio API as
> well !!!
When a user puts a patch online I am sure they want as many people as
possible to be able to use that patch, that's my only point. It's a
reality that more people on the planet use IE than any other browser (as
horrible as that fact is). If it's possible to support IE then we
should, for the sake of users.
Anyway, I think it just means I will have to maintain the Flash driver
myself, which is horrible, but I realise nobody else will want to touch
this. :)
Chris McCormick
> Let's see how things go. It's just that now I'm more careful, because I
> had the bad experience of coding a lot of stuff in a fork, and the
> author never pulling it, or pulling then reverting all the work done.
I understand your concern. However, in the age of distributed version
control I think it's not such an issue. Imagine the situation where the
scenario above happens:
* You start implementing lots of cool stuff.
* I turn into a jerk and stop merging it or revert it.
* People see that your version has lots more features.
* People run your version instead of mine.
In any case, I am happy to put a link from the current WebPd site to
your GitHub repository as soon as you make your first commit saying
"this is where the latest active development is now happening".
s p
From: s p <seb...@gmail.com>
Date: 2012/3/6
Subject: Re: WebPd - Need a small clarification
To: Chris McCormick <ch...@mccormick.cx>
> It's a reality that more people on the planet use IE than any other browser
> (as horrible as that fact is).
> Anyway, I think it just means I will have to maintain the Flash driver myself
> In any case, I am happy to put a link from the current WebPd
All in all, that's great !!! I'm eager to start ! I'll have more and more time, starting in 1 month, then I'll start doing the heavy changes.
Cheers !
Sébastien
sebastien piquemal
> It's a reality that more people on the planet use IE than any other browser
> (as horrible as that fact is).