You might also want to [set ( values to be displayed by your slider or number box.
i.e. better this
[your input] | [set ( | [vslider]
rather than
[your input] | [vslider]
When a slider receives a [set $1( message, it only displays the data, without executing any output. This is another good resources-saving method. Obviously we are talking about a situation in which you want to use a good amount of sliders and nboxes. Otherwise, as noted previously, one or two sliders do not really represent an issue.
Hiding massive GUI works also in my experience. cheers,
"One thing to keep in mind with Pd on modern computers is that 'pd-gui' is a totally separate process from 'pd', so since basically all laptops, desktops, and even tablets these days ship with 2 or more cores, that means 'pd-gui' and 'pd' will be running on separate cores. Therefore, as long as 'pd-gui' doesn't use more than say 70% of one core, it shouldn't affect 'pd' much at all."
Sorry for possible dumbness here but am I reading this right?:
I have a dual core laptop with a patch where I'm right at the top of my cpu. The patch utilises a sensor, audio input and [sigmund~], lots of synthesis, and a fairly complex quad panned output. On top of this there's some pmpd and GEM stuff.
I'm in the process of splitting the patch in half to try and gain some computing headroom, again. I had a quick go a couple of months ago but didn't get any noticeable boost - in fact the process of piping lots of data between the two instances of Pd seemed to cause more problems than it solved.
This is a long-winded way of asking whether there's any point in spreading the load if Pd is already utilising both cores?
Bit confused now but best wishes,
Julian
On 8 February 2012 17:55, Marco Donnarumma devel@thesaddj.com wrote:
You might also want to [set ( values to be displayed by your slider or number box.
i.e. better this
[your input] | [set ( | [vslider]
rather than
[your input] | [vslider]
When a slider receives a [set $1( message, it only displays the data, without executing any output. This is another good resources-saving method. Obviously we are talking about a situation in which you want to use a good amount of sliders and nboxes. Otherwise, as noted previously, one or two sliders do not really represent an issue.
Hiding massive GUI works also in my experience. cheers,
-- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK
Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey there,
i'm having a weird problem with wiimote. connecting and buttons work fine, but when i try to turn on some additional reporting, nothing happens. the device and bluetooth is ok, as i can get everything with wmgui, which also uses libcwiid, so i guess the library is ok too.
i added some debugging to post the arguments passed to the function wiimote_report and for some strange reason, while s->s_name comes out right, (int) onoff seems to be always 0! because i know i need the acceleration, i can brute force it into beeing enabled right away, but that's obviously not very elegant. i tried to go the comfortable way by apt-getting pd-wiimote, but it exhibits the same problem.
can someone help me understand, what's going on here?
i should mention that i'm on a 64bit system (ubuntu 10.04), which i know makes C code be compiled slightly different than intended at times. pd version is pd-extended 42.5 and the wiimote-external 0.3.2.
thanks and ciao, ub
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
thanks+ciao, ub
it still crashes a lot though, especially with
On 09.02.2012 12:34, ub@xdv.org wrote:
can someone help me understand, what's going on here?
Try disis_wiimote (http://l2ork.music.vt.edu/main/?page_id=56). We use it as the core controller inside L2Ork with over dozen machines in the same room and it has been rock solid for over 2 years. It is multithreaded so sending rumble/led messages back to Wiimote does not block Pd. It is also driven by metro so you can decide the granularity of updates. Supports MotionPlus, etc. Wii Fit support can be added I just didn't bother with it yet but it shouldn't be too hard...
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of ub@xdv.org Sent: Friday, February 10, 2012 9:48 AM To: pd-list@iem.at Subject: Re: [PD] wiimote report
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
thanks+ciao, ub
it still crashes a lot though, especially with
On 09.02.2012 12:34, ub@xdv.org wrote:
can someone help me understand, what's going on here?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Should I install this version of wait for Gilded Palace of Sin?! Ha! pp
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ivica Ico Bukvic Sent: Friday, February 10, 2012 10:39 AM To: ub@xdv.org; 'pd-list' Subject: Re: [PD] wiimote report
Try disis_wiimote (http://l2ork.music.vt.edu/main/?page_id=56). We use it as the core controller inside L2Ork with over dozen machines in the same room and it has been rock solid for over 2 years. It is multithreaded so sending rumble/led messages back to Wiimote does not block Pd. It is also driven by metro so you can decide the granularity of updates. Supports MotionPlus, etc. Wii Fit support can be added I just didn't bother with it yet but it shouldn't be too hard...
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of ub@xdv.org Sent: Friday, February 10, 2012 9:48 AM To: pd-list@iem.at Subject: Re: [PD] wiimote report
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
thanks+ciao, ub
it still crashes a lot though, especially with
On 09.02.2012 12:34, ub@xdv.org wrote:
can someone help me understand, what's going on here?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes I had similar problems and switching to [disis_wiimote] fixed all the crashes.
OT: is any of L2Ork going to be merged into Pd/PdX at some point? Seems like there are some good improvements going on there, for example unlimited undo.
-John
On Fri, Feb 10, 2012 at 9:39 AM, Ivica Ico Bukvic ico@vt.edu wrote:
Try disis_wiimote (http://l2ork.music.vt.edu/main/?page_id=56). We use it as the core controller inside L2Ork with over dozen machines in the same room and it has been rock solid for over 2 years. It is multithreaded so sending rumble/led messages back to Wiimote does not block Pd. It is also driven by metro so you can decide the granularity of updates. Supports MotionPlus, etc. Wii Fit support can be added I just didn't bother with it yet but it shouldn't be too hard...
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of ub@xdv.org Sent: Friday, February 10, 2012 9:48 AM To: pd-list@iem.at Subject: Re: [PD] wiimote report
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
thanks+ciao, ub
it still crashes a lot though, especially with
On 09.02.2012 12:34, ub@xdv.org wrote:
can someone help me understand, what's going on here?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
it still crashes a lot though, especially with
With what?
Roman
I will try disis when I get to my linux box, I could never get pd-wiimote to work for more than 20 minutes without a full pd crash so this is good news.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Roman Haefeli Sent: Friday, February 10, 2012 10:48 AM To: ub@xdv.org Cc: pd-list@iem.at Subject: Re: [PD] wiimote report
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
it still crashes a lot though, especially with
With what?
Roman
[1] http://l2ork.music.vt.edu/main/?page_id=56
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 2012-02-10 at 16:47 +0100, Roman Haefeli wrote:
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
Hm.. we have clearly more success stories with [disis_wimoote] than with [wiimote] pd-svn. Probably [disis_wiimote] should be in debian?
Roman
On 02/10/12 17:11, Roman Haefeli wrote:
Hm.. we have clearly more success stories with [disis_wimoote] than with [wiimote] pd-svn. Probably [disis_wiimote] should be in debian?
i don't know, it feels like we have clearly more bug reports for [wiimote] than for [disis_wiimote]
otoh, some debian statistics: pd-wiimote package has 0 (zero) bug-reports [1], and according to popcon, even more people have pd-wiimote installed than pd-osc (though the numbers are generally quite low, so maybe not very representative)
the problem with is, that people usually report bugs rather than success stories.
so here is one: i've been using [wiimote] (buttons, accel, motionplus) in 2 week installation, that was not turned off during the night.
mfgasdr IOhanens
[1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pd-wiimote
Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there
another
wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
and why couldn't a lot of people benefit from the disis_wiimote? it is open source and it's just a matter of packaging it for a specific distro.
it still crashes a lot though, especially with
With what?
Roman
[1] http://l2ork.music.vt.edu/main/?page_id=56
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
On 02/10/12 17:38, Ivica Ico Bukvic wrote:
and why couldn't a lot of people benefit from the disis_wiimote?
i think nobody challenged that.
it is open source and it's just a matter of packaging it for a
specific distro.
yes, somebody has to do the work.
btw, [wiimote] is open source as well (and it's already packaged for debian/ubuntu), so why shouldn't a lot people benefit from fixes for that code?
while i appreciate your work with pd-l2ork, i think it would be great if you would be trying to get the fixes into "upstream" (where you forked from).
fgmasdr IOhannes
while i appreciate your work with pd-l2ork, i think it would be great if you would be trying to get the fixes into "upstream" (where you forked from).
I did, but many fixes never got anywhere (we had this discussion a while ago), and while in the early days I spent most of my time providing additional documentation to Hans and others and making arguments on why they should be accepted which resulted in less than dozen fixes in the first year out of which only a few actually made it upstream, I am now running a fork that has 200+ improvements and fixes in approx. the same amount of time and have arrived at a rock-solid system* and have no interest in going back to a platform that may be stable on release and crash in another. Sure, I am missing a few novel features, but if the current version caters to my (perhaps somewhat specific) needs, there is no reason to go back.
FWIW, Hans has started taking some of our patches and merging it upstream (e.g. magicglass that I ported and cleaned up that has been sitting on the sourceforge database for over half a decade untouched) which is great and I would love to see the rest of it there as well. It is just that this way Hans will have to review it (which is something he would have to do anyhow), and merge it at his discretion, rather than me having to spend copious amounts of time to promote adoption of such patches and providing context that is difficult to make unless one spends some time studying the issue on their own...
*based on experiences from ongoing L2Ork rehearsals involving dozen or more networked performers.
Best wishes,
Ico
Well, what I understand is that pd-l2ork has already been synthesised as a pile of patches over pd 0.42. If I'm getting it right, disis_wiimote could be too, but is not yet, go on git as a set of patches over a certain version of wiimote, which would open the possibility to merge patches upstream. I don't know however if it's in anyone's interest to actually do it.
András
Not really, there are a bunch of features pd-l2ork has that pd and pd-extended dont have and even more bugfixes.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
"András Murányi" muranyia@gmail.com wrote:
Well, what I understand is that pd-l2ork has already been synthesised as a pile of patches over pd 0.42. If I'm getting it right, disis_wiimote could be too, but is not yet, go on git as a set of patches over a certain version of wiimote, which would open the possibility to merge patches upstream. I don't know however if it's in anyone's interest to actually do it.
András
On Feb 10, 2012, at 2:14 PM, Ivica Ico Bukvic wrote:
while i appreciate your work with pd-l2ork, i think it would be great if you would be trying to get the fixes into "upstream" (where you forked from).
I did, but many fixes never got anywhere (we had this discussion a while ago), and while in the early days I spent most of my time providing additional documentation to Hans and others and making arguments on why they should be accepted which resulted in less than dozen fixes in the first year out of which only a few actually made it upstream, I am now running a fork that has 200+ improvements and fixes in approx. the same amount of time and have arrived at a rock-solid system* and have no interest in going back to a platform that may be stable on release and crash in another. Sure, I am missing a few novel features, but if the current version caters to my (perhaps somewhat specific) needs, there is no reason to go back.
FWIW, Hans has started taking some of our patches and merging it upstream (e.g. magicglass that I ported and cleaned up that has been sitting on the sourceforge database for over half a decade untouched) which is great and I would love to see the rest of it there as well. It is just that this way Hans will have to review it (which is something he would have to do anyhow), and merge it at his discretion, rather than me having to spend copious amounts of time to promote adoption of such patches and providing context that is difficult to make unless one spends some time studying the issue on their own...
*based on experiences from ongoing L2Ork rehearsals involving dozen or more networked performers.
Its great that you are maintaining your own fork. I think everyone, including you, would benefit if your changes made it upstream. That takes work in the short run, but then you don't have to maintain those anymore because they are upstream. We've been doing this with Pd-extended for many years now.
pd-l2ork/pd-extended/pd-vanilla is the perfect example of what I was talking about before. There are bugfixes and features that are currently only in pd-l2ork. There are also features and bugfixes that are only in Pd-extended 0.43. As I develop features and test them in Pd-extended, I contribute them upstream to Miller. I really try not to send raw and not tested code to Miller.
When you were submitting patches before, I spent many hours trying to get your code to work. It often didn't run at all for me, or with things like your scrolling updates, it had egregious bugs. That time I spent trying to get your code to work was time I could have spent coding. It seems that you work much better with your own fork, then you can work out the problems and test them. But you have moved your fork quite far away from were pd-vanilla and pd-extended have gone.
I think the way forward is for you to start merging in changes from pure-data.git and pd-extended.git and getting closer in sync. Then you can maintain your own fork, and easily take patches from pure-data.git and pd-extended.git and vice-versa. git makes that process a lot easier if you dive in deep, so I recommend really getting to know it.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Feb 10, 2012, at 11:38 AM, Ivica Ico Bukvic wrote:
Roman Haefeli reduzent@gmail.com wrote:
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there
another
wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
and why couldn't a lot of people benefit from the disis_wiimote? it is open source and it's just a matter of packaging it for a specific distro.
Why have two wiimote objects? Is there a specific reason why they can't be merged? If we pool the work on it we'll have one better wiimote object versus two different wiimote objects that are both less good.
.hc
“We must become the change we want to see. - Mahatma Gandhi
Why have two wiimote objects? Is there a specific reason why they can't be merged? If we pool the work on it we'll have one better wiimote object versus two different wiimote objects that are both less good.
Do you mind elaborating why you believe both objects are "less good" in and of themselves? IMO disis_wiimote is much more robust than the wiimote object (at least the last time I tested) in every respect and provides entirely xrun-free functionality. If we agree the aforesaid statement is true (not that I am suggesting that you do agree) then it is not that both are less good but rather the one is better than the other literally in every respect which should in theory make the whole process of selection a lot simpler.
Also, suggested pooling may not be always the best approach, particularly if there is limited transparency in terms of how such process is managed (which BTW I think is the core reason why pd-l2ork and disis_wiimote exist in the first place, and consequently why pd community at large is having trouble with the uptake). Also, let us not forget that at the very core of the open-source idea is the "survival of the fittest" model (with a caveat, however; read * below). This means if one external works better than another, it will simply supersede its operation, particularly if their output is essentially the same. Renaming it (or using other practical alternatives to "pooling"), provided credit is given where credit is due, is at this point irrelevant and should be considered synonymous to pooling, particularly in this case where disis_wiimote AFAIK does everything wiimote does except it does it in a way that is (IMO) more robust**
*Of course, any dev has every right to continue to maintain their own version for whatever reason and thus defy the context of the survival of the fittest regardless whether they are maintaining one of the "fittest" or less "fit" versions. Also, obviously everyone is entitled to their own definition of what constitutes "fittest" iteration...
**Based on 2.5+ years of experience of having a bunch of students with no prior Linux/PD experience messing with the system, including the wiimote external. I hope others would agree that the object's stability is best tested when used by others than the developer who usually focuses on aspects that best cater to their own needs and that may not be always as all-encompassing to cover all use cases. Thus, the greatest collection of instabilities will surface through third-party use. The same is true for pd as a whole...
Best wishes,
Ico
On Feb 10, 2012, at 2:05 PM, Ivica Ico Bukvic wrote:
Why have two wiimote objects? Is there a specific reason why they can't be merged? If we pool the work on it we'll have one better wiimote object versus two different wiimote objects that are both less good.
Do you mind elaborating why you believe both objects are "less good" in and of themselves? IMO disis_wiimote is much more robust than the wiimote object (at least the last time I tested) in every respect and provides entirely xrun-free functionality. If we agree the aforesaid statement is true (not that I am suggesting that you do agree) then it is not that both are less good but rather the one is better than the other literally in every respect which should in theory make the whole process of selection a lot simpler.
Also, suggested pooling may not be always the best approach, particularly if there is limited transparency in terms of how such process is managed (which BTW I think is the core reason why pd-l2ork and disis_wiimote exist in the first place, and consequently why pd community at large is having trouble with the uptake). Also, let us not forget that at the very core of the open-source idea is the "survival of the fittest" model (with a caveat, however; read * below). This means if one external works better than another, it will simply supersede its operation, particularly if their output is essentially the same. Renaming it (or using other practical alternatives to "pooling"), provided credit is given where credit is due, is at this point irrelevant and should be considered synonymous to pooling, particularly in this case where disis_wiimote AFAIK does everything wiimote does except it does it in a way that is (IMO) more robust**
*Of course, any dev has every right to continue to maintain their own version for whatever reason and thus defy the context of the survival of the fittest regardless whether they are maintaining one of the "fittest" or less "fit" versions. Also, obviously everyone is entitled to their own definition of what constitutes "fittest" iteration...
**Based on 2.5+ years of experience of having a bunch of students with no prior Linux/PD experience messing with the system, including the wiimote external. I hope others would agree that the object's stability is best tested when used by others than the developer who usually focuses on aspects that best cater to their own needs and that may not be always as all-encompassing to cover all use cases. Thus, the greatest collection of instabilities will surface through third-party use. The same is true for pd as a whole...
Best wishes,
For one thing, I cannot "apt-get install pd-disis-wiimote". Another thing, I know that pd-wiimote has had quite a bit of testing when using 6 wiimotes simultaneously.
You are of course free to do whatever you want with the code, no one is challenging that. I am talking about contributing patches upstream. That's widely accepted as the best practice, and then forking is a good second option.
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On 10.02.2012 16:47, Roman Haefeli wrote:
On Fri, 2012-02-10 at 15:48 +0100, ub@xdv.org wrote:
to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off.
it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux?
Yeah, there is also [disis_wiimote] [1] from the L2ork project.
Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix?
there you go. but i'm still wondering a bit, why that wouldn't affect everyone else too. 64bit? i'll try disis_wiimote and file a bug report for wiimote with debian. :)
thanks+ciao, ub
-
András Murányi -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Ivica Ico Bukvic -
John Harrison -
Julian Brooks -
Marco Donnarumma -
Pagano, Patrick -
Roman Haefeli -
ub＠xdv.org