Re: New GUI tests
Chris McCormick
>hi Vilson, you are totally right about the dom-based advantages.
>I like jquery too, im very excited to see your demos.
>
>please check out
>http://www.spencerwaterbed.com/soft/webpd/
>there are a billion bugs but I work on it when I can.
>
>I'll admit it, I've exposed myself to quite a big project doing it in
>the canvas from primitives.
>its a steep hill to climb, and it does redraw it all 24 times a second
>etc.
>but there are advantages to this aswell.
>I think you'll find theres alot going on, you know, with interaction
>and stuff. Speed has never actually been an issue either, 20fps is
>fine for this, and canvas is about to fly, big time, in ff4. The audio
>stuff I think will be many times more taxing on the cpu than the
>graphical stuff.
>
>smarter programmers than I have made the canvas sing, and I hope we
>can converge on a platform that isn't a compromise.
>
>right now you can build a pd patch graphically, load it from pd
>source, manipulate it, save it as valid pdsource. its got most of the
>unique gui objects, like sliders, toggles- its working 'right in'
>pd.js. moving, deleting, copy/paste, edit mode logic, kboard
>shortcuts, no lag problems, a clumsy object zoom, clumsy object
>browser/help integration - plans for abstraction support, automatic
>connects, a nl command interface. ..even tentative max-msp conversion.
>
>if you wanna take a peek at the code, it lives right off of the pd.js
>objects. when you click play it converts the live manipulated objects
>back into a pd string, then loads it again in pd.js.
>
>glad the 4 of us have come together on this. I've wanted to build this
>for a long time. My roomate from france was like 'oh ya, puredata',
>and he's a carpenter. its so popular, but so brutaly old-fashioned. I
>have to squint to see those damn little inlets.
>
>chris, could you parse comments (text objects) in pd.js? I don't want
>to have to re-parse the pd file to find them. I've added a 'text'
>object that does nothing. That would be really helpful.
>
>can someone take a crack at metro? that's a missing puzzle piece. also
>connection fanning. That would be really awesome.
>can pd.js do abstractions?
>
>trying to polish things this week. way too far into this to give up
>
>On Mon, Dec 27, 2010 at 1:18 PM, Vilson Vieira <vil...@void.cc> wrote:
>> Hello,
>>
>> this weekend I did some tests for GUI ideas I have for web-pd. I've
>> created a repos here:
>>
>> https://github.com/automata/web-pd-gui
>>
>> There is a simple demo:
>>
>> http://automata.github.com/web-pd-gui/test_jsplumb.html
>>
>> It's just a proof of concept (we can create just osc~ and dac~) and
>> buggy! For example: moving boxes breaks the PD running. Any
>> suggestion?
>>
>> I think using DOM elements as GUI to web-pd have some advantages:
>it's
>> DOM elements :-) so we can use existing UI JavaScript APIs like
>jQuery
>> UI, we don't need to write everything from scratch. It is not "draw
>> frame" based, so the CPU load is decreased. We can mix web-pd with
>> other HTML5 elements like video, canvas and SVG. We can use CSS to
>> create themes to the GUI.
>>
>> I've tested other "dataflow diagrams" JS APIs. jsPlumb is my choice
>> because it's simple, beautiful, DOM based and uses jQuery.
>>
>> RaphaelJS is interesting and fast to draw diagrams:
>>
>> http://automata.github.com/web-pd-gui/test_raphaeljs.html
>>
>> but it generates SVG, not DOM elements. Maybe we can use that or
>> ProcessingJS to draw canvas-related things like waveforms.
>>
>> I didn't touch pd.js. I'm using just pd.parse() and pd._graph to get
>> crucial information about the objects (number of inlets, type, number
>> of arguments, ...).
>>
>> Well, I'm so excited about web-pd and all HTML5 audio thing! Please,
>> I'd like to know what do you guys think.
>>
>> All the best.
>>
>> --
>> Vilson Vieira
>>
>> vil...@void.cc
>>
>> ((( http://automata.cc )))
>>
>> ((( http://musa.cc )))
>>
Good news everyone, tonight i got a working [metro] after a few days intermittent hacking. No proper net access at the moment, but i will commit my changes tomorrow when I'm back on broadband.
Next stop, connection fanning (but don't hold your breath)!
I may actually do [timer] first, while my head is in the scheduling/clock stuff.
Cheers,
Chris.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Chris McCormick
I have now comitted the [metro] implementation and the new scheduling methods
on the pd class, to Google Code SVN. Enjoy.
Cheers,
Chris.
-------------------
http://mccormick.cx
Brandon James
I just knocked together a quick metro test patch and it worked
perfectly.
I did notice earlier today that the pd console doesn't seem to work
anymore for me though.
Anybody else have that problem or is it just on my end?
Also, now that I can shift timing responsibility over to pd where it
should be, what is the best way to get that info back out so I can use
it for visual feedback etc?
Is there already a method in place for this, or do we need something
like pd.receive() to match pd.send()?
Chris McCormick
We definitely need pd.receive(). I will add it to my list.
Hopefully I will get more time to work on this stuff. I at least want to get it
to the point where the basic Pd architecture is supported so you guys can
continue with making objects.
My wife and I just had a baby though, so who knows how long it will take me.
Cheers,
Chris.
On Mon, Jan 24, 2011 at 08:37:31PM -0800, Brandon James wrote:
> Very cool Chris, thank you.
>
> I just knocked together a quick metro test patch and it worked
> perfectly.
>
> I did notice earlier today that the pd console doesn't seem to work
> anymore for me though.
> Anybody else have that problem or is it just on my end?
>
> Also, now that I can shift timing responsibility over to pd where it
> should be, what is the best way to get that info back out so I can use
> it for visual feedback etc?
> Is there already a method in place for this, or do we need something
> like pd.receive() to match pd.send()?
>
> On Jan 24, 7:20ï¿œpm, Chris McCormick <ch...@mccormick.cx> wrote:
> > Hello everyone,
> >
> > I have now comitted the [metro] implementation and the new scheduling methods
> > on the pd class, to Google Code SVN. Enjoy.
> >
> > Cheers,
> >
> > Chris.
> >
> > -------------------http://mccormick.cx
-------------------
http://mccormick.cx
Brandon James
Congratulations on the new person! That must be way more interesting
than coding [metro], so double thanks for that one.
No hurry on receive() of course, I just wanted to be sure I was
looking in the right place and not missing something obvious.
My goal is to create a sort of online 'Mix Station' as a
presentation for my music, that plays the track a new way every time
and allows the listener to interact with it at whatever level they
feel like. The only piece missing now is getting the timing info back
from pd so I can set up a transport section with p5js.
I've been coding in java for the past few months, so it's taking me a
minute to get back into the js way of things, but I'll see if I can
hack something together over the next few days.
Brandon
On Jan 24, 8:45 pm, Chris McCormick <ch...@mccormick.cx> wrote:
> Hi Brandon,
>
> We definitely need pd.receive(). I will add it to my list.
>
> Hopefully I will get more time to work on this stuff. I at least want to get it
> to the point where the basic Pd architecture is supported so you guys can
> continue with making objects.
>
> My wife and I just had a baby though, so who knows how long it will take me.
>
> Cheers,
>
> Chris.
>
>
>
>
>
>
>
>
>
> On Mon, Jan 24, 2011 at 08:37:31PM -0800, Brandon James wrote:
> > Very cool Chris, thank you.
>
> > I just knocked together a quick metro test patch and it worked
> > perfectly.
>
> > I did notice earlier today that the pd console doesn't seem to work
> > anymore for me though.
> > Anybody else have that problem or is it just on my end?
>
> > Also, now that I can shift timing responsibility over to pd where it
> > should be, what is the best way to get that info back out so I can use
> > it for visual feedback etc?
> > Is there already a method in place for this, or do we need something
> > like pd.receive() to match pd.send()?
>
Chris McCormick
That sounds very cool indeed. pd.receive() should take a sender name and a
callback as arguments like this:
pd.receive("myreceiver", function() { alert('yes'); });
This should not actually be super difficult to put in there so maybe I will get
around to it sooner rather than later.
Note that like Pd itself, the messages won't arrive out of WebPd at the exact
time they are supposed to - they will always arrive on block boundaries. What
this means is you might have plus or minus two or three milliseconds on the
actual time they were meant to land. I don't think this is unacceptable for
most applications.
Cheers,
Chris.
On Mon, Jan 24, 2011 at 09:20:31PM -0800, Brandon James wrote:
> Chris,
> Congratulations on the new person! That must be way more interesting
> than coding [metro], so double thanks for that one.
>
> No hurry on receive() of course, I just wanted to be sure I was
> looking in the right place and not missing something obvious.
>
> My goal is to create a sort of online 'Mix Station' as a
> presentation for my music, that plays the track a new way every time
> and allows the listener to interact with it at whatever level they
> feel like. The only piece missing now is getting the timing info back
> from pd so I can set up a transport section with p5js.
> I've been coding in java for the past few months, so it's taking me a
> minute to get back into the js way of things, but I'll see if I can
> hack something together over the next few days.
>
> Brandon
>
-------------------
http://mccormick.cx
Vilson Vieira
> Hello everyone,
Hello Chris,
> I have now comitted the [metro] implementation and the new scheduling methods
> on the pd class, to Google Code SVN. Enjoy.
I'll check that soon. Thanks!
BTW do you have any idea why [1] stops the sound when I move the
objects on the page? Maybe because it's not multithreaded? Any
suggestions?
Cheers.
[1] http://automata.github.com/web-pd-gui/test_jsplumb.html
Brandon James
So I've created a [send] object that just calls pd.send().
I didn't really see any reason to keep them separate.
What I'm not sure of is how to call pd.receive() from [send],
since the external receiver wont be part of pd.listeners[].
From what you wrote above, I get that the basic gist of pd.receive()
should be something like
this.receive(name,callback){
if(name sends a message){
callback;
}
}
but how do I tell it that name sent a message?
Apologies if this is a basic programming question, as I said before,
I'm learning as I go.
Thanks,
Brandon
Brandon James
the callbacks instead of receive objects?
Or is there a way to stick them into the already existing listeners
array?
Am I even on the right track?
Join us next week on "Hacking and Stumbling through the jungles of
WebPd" to find out.
Chris McCormick
That's right, you should just be able to stick it in the list of internal
receivers.
So what you want to do is call addlistener with an argument who which is a
simple javascript object with an attribute "message" that calls the external
callback. Something like this (untested code):
pd.addlistener(receivername, {"message": function(d, value) { callback(value); } });
Where 'callback' is the callback that the user supplied, and 'receivername' is
the name of the function.
Note that internal Pd style messages don't yet do what they are meant to. Like
if you have a message box with [; myreceiver blah blah;( in Pd the receiver
myreceiver will get the value blah blah when that message is fired, but in
WebPd I haven't implemented that yet. If you want a crack at it, start with the
"msg" internal object on line 693. Right at the end of that object there is a
TODO which reads:
// TODO: else inject other messages back into the graph based on first atom name
It should probably inject those using the send method you just made.
Hmmm, I hope this all makes sense!
Cheers,
Chris.
On Wed, Jan 26, 2011 at 01:53:35AM -0800, Brandon James wrote:
> Should there maybe be a new array of external listeners that contains
> the callbacks instead of receive objects?
> Or is there a way to stick them into the already existing listeners
> array?
> Am I even on the right track?
>
> Join us next week on "Hacking and Stumbling through the jungles of
> WebPd" to find out.
>
> On Jan 26, 1:39ï¿œam, Brandon James <xbrandonjam...@gmail.com> wrote:
> > Hi everyone,
> >
> > So I've created a [send] object that just calls pd.send().
> > I didn't really see any reason to keep them separate.
> >
> > What I'm not sure of is how to call pd.receive() from [send],
> > since the external receiver wont be part of pd.listeners[].
> >
> > From what you wrote above, I get that the basic gist of pd.receive()
> > should be something like
> >
> > this.receive(name,callback){
> > ￜ ￜ if(name sends a message){
> > ￜ ￜ ￜ ￜ callback;
> > ￜ ￜ }
> >
> > }
> >
> > but how do I tell it that name sent a message?
> >
> > Apologies if this is a basic programming question, as I said before,
> > I'm learning as I go.
> >
> > Thanks,
> > ￜ Brandon
> >
> > On Jan 25, 5:18ï¿œam, Vilson Vieira <vil...@void.cc> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > 2011/1/25 Chris McCormick <ch...@mccormick.cx>:
> >
> > > > Hello everyone,
> >
> > > Hello Chris,
> >
> > > > I have now comitted the [metro] implementation and the new scheduling methods
> > > > on the pd class, to Google Code SVN. Enjoy.
> >
> > > I'll check that soon. Thanks!
> >
> > > BTW do you have any idea why [1] stops the sound when I move the
> > > objects on the page? Maybe because it's not multithreaded? Any
> > > suggestions?
> >
> > > Cheers.
> >
> > > [1]http://automata.github.com/web-pd-gui/test_jsplumb.html
> >
> > > --
> > > Vilson Vieira
> >
> > > vil...@void.cc
> >
> > > (((http://automata.cc)))
> >
> > > (((http://musa.cc)))
-------------------
http://mccormick.cx
Chris McCormick
On Tue, Jan 25, 2011 at 11:18:04AM -0200, Vilson Vieira wrote:
> BTW do you have any idea why [1] stops the sound when I move the
> objects on the page? Maybe because it's not multithreaded? Any
> suggestions?
It won't have anything to do with threading. I will have to investigate, but
might not get time to do that soon. Maybe you can provide more info here?
Brandon James
hours to no avail.
This is what I have so far.
In pd.js I've added
this.receive = function(name,callback){
this.pd.addlistener(name,{"message":function(d,val){
callback(val);
}
}
);
}
which is basically copied right from your posts.
I'm assuming 'd' is just a placeholder arg for inletnum, and so could
be checked against -1, but I left that out for now to keep it simple.
In my p5.js front end I stuck this in the draw loop
pd.receive("note",function(arg1){me.background(arg1);});
where 'me' has been set to the PApplet and 'note' is the name of the
send.
I've tried to format the call to pd.receive all types of ways; both
with and without the argument and the closure, but so far nothing
works.
It runs fine, but doesn't change the bg color.
I'm guessing I'm not passing the callback correctly.
Any light you can shed on the subject is much appreciated.
Brandon
Chris McCormick
I would start by doing a console.log() or an alert() to test instead of setting
a background - that way you can be sure the receive callback is actually
getting a value. Also put a receiver in the patch connected to a [print] object
just so you can be sure that what is being sent is what you think is being
sent. How are you doing the sending, with your new [send] object? Did you also
make aliases from [send]/[receive] to [s]/[r]?
Cheers,
Chris.
-------------------
http://mccormick.cx
Brandon James
updated to the new version with metro.
I'm not sure if this is because I migrated to a new system, or if
something got broke last update.
And to be honest, I was too lazy, or just unwilling to learn how to
print to the screen with html, so I used an audible cue to check a s/r
pair instead, and that works fine.
I did create the aliases, and they work too.
But yeah, I figured just using the regular send/receive objects would
be the best way to interface with pd from the rest of the code, so
that's what I used.
That way you can test your patch in pd using the native controls'
internal sends, and just name equivalent controls in whatever front
end you might use.
I'll do some poking and see if I can figure out where the console
went, or short of that, rig some kind of cue in the pd.receive()
function.
I'm pretty sure pd.receive is being called ok because if I stick some
bad code in there it crashes.
I think the problem lies in the fact that I don't know how to properly
set up a callback in javascript, and google's been lees than helpful
so far.
I'll keep at it. Eventually I'm bound to stumble on to the solution.
Thanks,
Brandon
Chris McCormick
What is super helpful is the Firebug plugin for Firefox. WebPd logs a ton of
stuff which you can see in the firebug console. You can also do heaps of other
great stuff like tracing back through the code when there is an error etc. It
just all round makes Javascript development easier.
Let me know if you get anywhere or if you get stuck and I can help. Also let me
know when stuff is working so I can pull your code into my repo.
Cheers,
Chris.
> > > ￜ ￜthis.receive = function(name,callback){
> > > ￜ ￜ ￜ ￜ ￜ ￜthis.pd.addlistener(name,{"message":function(d,val){
> > > ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜcallback(val);
> > > ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ}
> > > ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ }
> > > ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ ￜ );
> >
> > > ￜ ￜ}
> >
> > > which is basically copied right from your posts.
> > > I'm assuming 'd' is just a placeholder arg for inletnum, and so could
> > > be checked against -1, but I left that out for now to keep it simple.
> >
> > > In my p5.js front end I stuck this in the draw loop
> >
> > > ￜ ￜpd.receive("note",function(arg1){me.background(arg1);});
> >
> > > where 'me' has been set to the PApplet and 'note' is the name of the
> > > send.
> > > I've tried to format the call to pd.receive all types of ways; both
> > > with and without the argument and the closure, but so far nothing
> > > works.
> > > It runs fine, but doesn't change the bg color.
> > > I'm guessing I'm not passing the callback correctly.
> > > Any light you can shed on the subject is much appreciated.
> >
> > > Brandon
> >
> > > On Jan 26, 4:54 am, Chris McCormick <ch...@mccormick.cx> wrote:
> > > > Hi Vilson,
> >
> > > > On Tue, Jan 25, 2011 at 11:18:04AM -0200, Vilson Vieira wrote:
> > > > > BTW do you have any idea why [1] stops the sound when I move the
> > > > > objects on the page? Maybe because it's not multithreaded? Any
> > > > > suggestions?
> >
> > > > It won't have anything to do with threading. I will have to investigate, but
> > > > might not get time to do that soon. Maybe you can provide more info here?
> >
> > > > Cheers,
> >
> > > > Chris.
> >
> > > > -------------------http://mccormick.cx
> >
> > -------------------http://mccormick.cx
-------------------
http://mccormick.cx
Brandon James
it wouldn't work with the beta.
I just got the alpha version though and it works.
I've only taken a quick look, but this should be really nice. Thanks
again.
I'll let you know how it turns out.
Brandon
> > > Hi Brandon,
>
> > > I would start by doing a console.log() or an alert() to test instead of setting
> > > a background - that way you can be sure the receive callback is actually
> > > getting a value. Also put a receiver in the patch connected to a [print] object
> > > just so you can be sure that what is being sent is what you think is being
> > > sent. How are you doing the sending, with your new [send] object? Did you also
> > > make aliases from [send]/[receive] to [s]/[r]?
>
> > > Cheers,
>
> > > Chris.
>
> > > On Wed, Jan 26, 2011 at 04:32:22PM -0800, Brandon James wrote:
> > > > >Hmmm, I hope this all makes sense!
>
> > > > Well, I thought it did, but I've been twiddling around with this for
> > > > hours to no avail.
>
> > > > This is what I have so far.
>
> > > > In pd.js I've added
>
> > > > this.pd.addlistener(name,{"message":function(d,val){
> > > > callback(val);
> > > > }
> > > > }
> > > > );
>
> > > > }
>
> > > > I'm assuming 'd' is just a placeholder arg for inletnum, and so could
> > > > be checked against -1, but I left that out for now to keep it simple.
>
> > > > In my p5.js front end I stuck this in the draw loop
>
Brandon James
I'll clean up the code a bit and try to push it through tomorrow.
It turns out
this.pd.addlistener(name,{"message":function(d,val){
didn't need a this, which makes sense.
And also the call to background() didn't need a closure.
Chris McCormick
Wonderful! Can't wait to integrate the code. Now that we have [metro] and we
can get data back out of Pd thanks to your receive() method, this opens up some
excellent opportunities.
If I had any time I'd revive my long-term dream of a web based collaborative
music tracker where you can co-compose and see eachother's edits in real-time.
That was actually my original motivation for starting WebPd.
Also I haven't forgotten about those fanning connections I need to fix.
Will look at your synth you sent through later tonight.
Thanks again for your great work!
Chris.
On Thu, Jan 27, 2011 at 01:59:03AM -0800, Brandon James wrote:
> Lol, so that took all of 30 seconds to figure out.
>
> I'll clean up the code a bit and try to push it through tomorrow.
>
> It turns out
>
> this.pd.addlistener(name,{"message":function(d,val){
>
> didn't need a this, which makes sense.
>
> And also the call to background() didn't need a closure.
>
>
>
> On Jan 27, 1:50ï¿œam, Brandon James <xbrandonjam...@gmail.com> wrote:
> > Hah, I had actually tried to install that earlier today, but it said
> > it wouldn't work with the beta.
> > I just got the alpha version though and it works.
> >
> > I've only taken a quick look, but this should be really nice. Thanks
> > again.
> > I'll let you know how it turns out.
> >
> > Brandon
> >
> > > > ￜ Brandon
-------------------
http://mccormick.cx
Brandon James
pd.receive() should be placed in the setup function, not the draw
loop.
Brandon James
>music tracker where you can co-compose and see eachother's edits in real-time.
>That was actually my original motivation for starting WebPd.
Console seems like a good rough start.
One of the directions I was thinking of taking it was a type of
multiplayer 'game' where the things you do, as well as the actions of
other 'players' connected to the same 'song' have a direct effect on
the music you hear. Kind of like group remixing with unconventional
tools.
My first thought was a type of 1st person explorer a'la Myst, but
there's no reason each song/world couldn't have it's own unique
platform.
Really, as these things come together, it ought to become easier and
easier to adapt them to all types of new cool possibilities and
interactions.
It might be worth trying to decide on a core set of functionality that
such a system should have, so as to make it adaptable as possible.
Things like how automation and modulation should be set up etc.
Over the next few weeks I'll try to get one of my songs set up in a
presentable form and see how it works out.
That synth I posted was really more of a learning experiment, as well
as a test to see how well setInterval and setTimeout worked for
sequencing (not very well).
But I got hours of fun from it anyway.
The sequencers will all stay synced on the long term, but drift
slightly from step to step.
Pardon the book I just wrote, these things just excite me.
Brandon
Brandon James
that soon.
B