Re: [PD] [PD-announce] pd 0.45-0 released
'hover' over the right-hand side of any object/message/comment in edit mode and the cursor should change to a 'grow' cursor (double arrow) - then drag to the left or right. enjoy... Miller On Fri, Aug 23, 2013 at 06:42:47PM -0300, Alexandre Torres Porres wrote: Objects/messages/comments have settable box widths. hi there, please, how can I use this new feature? I didn't get it. cheers 2013/8/23 Miller Puckette m...@ucsd.edu Hi all, Pd version 0.45-0 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout -b 0.45 As always I'm sure there will be problems here and there - you're welcome to report them on the Pd mailing list (pd-list@iem.at) which is always the fastest way to get me to see them. cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] midirealtimein error message, is it still needed?
Cool... I can take the message out :) M On Thu, Aug 22, 2013 at 08:52:28PM +0200, Max wrote: i can confirm it seems to work fine in 0.45-0 test3 on OS X midirealtimein: works under MSW only Am 14.12.2008 um 15:01 schrieb hard off hard@gmail.com: was just messing round with [midirealtimein] on linux. no problem it seems. my friend in berlin got it going fine on os x. so, is there still any need for the 'error: midirealtimein only works under MSW' message that is sent to the console upon load? ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD on retina display
Here's another possible approach... to get the dialogs etc to look OK you
can comment out the line tk scaling 1 in tcl/pd-gui.tcl (a long confused
thread on this: http://lists.puredata.info/pipermail/pd-dev/2013-06/019517.html)
and then to get the actual patch contents to look OK again, try to change
the scaling of canvases using this: http://wiki.tcl.tk/4844
I don't have any way to test all this (no 'retina display' - I use a desktop
machine - and anyway I'd rather swallow broken glass than use a Macintosh
today).
cheers
Miller
On Wed, Aug 21, 2013 at 04:29:43PM -0400, Jean-Michel Dumas wrote:
lol I knew someone would post something like that and i'm aware of ways to
do that (though not sed, since you have to be a wizard and/or a machine to
use that). i'm still keeping that line, could be handy sometime, thanks.
i'm working between multiple machines from a centralized patch repository,
which means fixing the look of all the patches for one will render them
weird looking on the others. my main patching machine is running Ubuntu and
everything looks fine on it. the gig machine I need stuff to look good on
is a new macbook, hence the retina display.
anyway, the fact remains that all dialogs and menu bars and titles stay
ugly even if I can partially fix the patches by reducing font size.
i'm guessing it's XQuartz's fault somehow, but I know nothing about it or
how to change the display mode.
jm
Jean-Michel Dumas
http://www.jmdumas.org
http://magasin.bandcamp.com
On Wed, Aug 21, 2013 at 4:05 PM, IOhannes m zmölnig zmoel...@iem.at wrote:
On 08/21/13 21:09, Jean-Michel Dumas wrote:
the pixel doubled mode problem stays for dialogs, titles and menus,
plus I really don't want to go through all my old patches and change the
font size! ;)
why not? it should be quite simple:
$ find . -type f -name *.pd -exec \
sed -i -e '/^#N canvas/s/12;$/10;/' \{\} \;
fgmdras
IOhannes
___
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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] pd 0.45 test 3
Have at it... test 3 is now up on the usual... http://crca.ucsd.edu/~msp/software.htm or git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout -b 0.45 0.45-0test3 Hopefully this fixes all the bugs that have shown up on pd-list so far. cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Pd version 0.25-0 test 2 released
Hi all - Thanks for the helpful reports about test 1 - I've now put out test 2 that (I hope) fixes all the problems that popped up today except that I don't know where the ASIO problems are coming from yet... I'll keep fooling with that. It's on: http://crca.ucsd.edu/~msp/software.htm or: git clone git://git.code.sf.net/p/pure-data/pure-data (I hope I fixed the trouble I was having with the git repo yesterday) Comments or bug reports welcome to pd-list.iem.at (or submit them correctly on sourceforge if you want a slower response :) cheers Miller (P.S. the git repo is now somewhat ahead of the compiled versions; this message got bounced the first time and should have gone out hours ago.) ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
Ok, thanks - I've unwound that one too. I'll hold off thinking about where to put 'man' - it mneeds to be coherent with where the source code looks for it and I've lost track of how that all works. cheers M On Mon, Aug 19, 2013 at 04:42:14PM +0200, IOhannes m zmölnig wrote: On 08/19/13 16:27, IOhannes m zmölnig wrote: On 08/19/13 07:43, Miller Puckette wrote: OK... I left these ones out: pd2puredata.patch usrlibpd_path.patch fixmanpage.patch helpbrowser_puredata-doc.patch since I think they're debian-specific; took the other 11. Thanks - they look helpful! thanks for taking them in. oops, i just noticed one patch that was included and probably should not have been: in debian we patch away the use of the internal portaudio/portmidi libraries in order to use the system installed libraries. this is most likely not wanted with the ordinary Pd distribution, so it might be a good idea to revert patch 5f2af0674 and to resolve some confusion about Debian and BSD: while Debian is mainly using linux as the underlying kernel, there are also flavours with using GNU/hurd and BSD as the underlying kernel - hence the patches. i guess Debian is the system that most often compiles Pd on a BSD-platform (using the autobuilds; no idea how many people actually use it that way) fgmasdr IOhannes ___ 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
Re: [PD] [PD-announce] Pd version 0.25-0 test 2 released
That's a bug fix :) To get the buggy (have-to-multiply-by-the-upsampling-multiple) behavior back, send a message ; pd compatibility 0.43 I need to make this very clear in the documnetation; and I now think the compatiibillity level should have been set to 0.44 instead - I'll fix that. cheers Miller On Mon, Aug 19, 2013 at 12:13:35PM +0200, martin brinkmann wrote: On 08/19/2013 08:11 AM, Miller Puckette wrote: Hi all - I've now put out test 2 there seems to be a new behaviour concerning tabread4~ and upsampling: (compared to 044, i have not checked the 1st 045 version) in 044 the frequency of the phasor reading the table had to be multiplied by the upsampling factor, to get the right output frequency. in 045 the output frequency of such oscillators much higher. this seems to happen only with tabread(4)~, the example in 'j07 oversampling' works as expected, but many of my bass-synth-patches sound a little squeaky now. ;) i have attached an example with tabread4~. #N canvas 130 266 876 628 10; #X obj 562 67 until; #X obj 562 95 f; #X obj 593 97 + 1; #X obj 557 154 t f f; #X obj 564 13 loadbang; #X obj 594 118 mod 515; #X msg 564 40 515; #X obj 529 633 table \$0triwave 515; #X obj 419 268 mod 512; #X obj 474 545 tabwrite \$0triwave; #X obj 513 354 * 2; #X obj 510 380 - 1; #X obj 433 406 *; #X obj 420 295 t f f; #X obj 431 432 / 512; #X obj 507 331 256; #X obj 455 458 -; #X obj 474 483 * 4; #X obj 473 516 + 3; #X obj 445 222 + 128; #X text 475 16 make tri wave; #X obj 78 462 dac~; #X obj 57 418 *~; #N canvas 316 285 1183 715 triosctest 0; #X obj 31 100 phasor~; #X obj 41 74 inlet~; #X obj 45 434 outlet~; #X text 88 75 freq; #X obj 49 183 tabread4~ \$0triwave; #X obj 50 329 *~ 0.125; #X obj 50 352 rzero~ -1; #X obj 50 375 rzero~ -1; #X obj 50 398 rzero~ -1; #X obj 49 203 *~ 0.2368; #X obj 50 249 *~ 0.06261; #X obj 49 226 rpole~ 0.76319; #X obj 49 272 cpole~ 0.85223 0.20194; #X obj 48 300 cpole~ 0.85223 -0.2019; #X text 150 347 filter from pd doc j07.oversampling (modified for 8 times oversampling); #X obj 50 148 *~ 512; #X obj 166 83 block~ 64 1 8; #X text 95 433 filtered tabread; #X connect 0 0 15 0; #X connect 1 0 0 0; #X connect 4 0 9 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 2 0; #X connect 9 0 11 0; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 12 0 13 0; #X connect 12 1 13 1; #X connect 13 0 5 0; #X connect 15 0 4 0; #X restore 5 261 pd triosctest; #X obj 101 369 hsl 128 15 0 1 0 1 empty empty empty -2 -8 0 10 -262144 -1 -1 1400 1; #X obj -8 155 nbx 5 14 -1e+37 1e+37 0 1 empty empty empty 0 -8 0 10 -262144 -1 -1 100 256; #X text 101 348 tabread osc; #X obj -5 209 * 8; #X text 45 180 in 44.1 this ensures the correct frequency with 8 times oversampling. in 045.test2 the frequency is much higher; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 3 0; #X connect 2 0 5 0; #X connect 3 0 19 0; #X connect 3 1 9 1; #X connect 4 0 6 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 8 0 13 0; #X connect 10 0 11 0; #X connect 11 0 12 1; #X connect 12 0 14 0; #X connect 13 0 12 0; #X connect 13 1 15 0; #X connect 14 0 16 0; #X connect 15 0 10 0; #X connect 15 0 16 1; #X connect 16 0 17 0; #X connect 17 0 18 0; #X connect 18 0 9 0; #X connect 19 0 8 0; #X connect 22 0 21 0; #X connect 22 0 21 1; #X connect 23 0 22 0; #X connect 24 0 22 1; #X connect 25 0 27 0; #X connect 27 0 23 0; ___ 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
Re: [PD] Limit bandwith for MIDI output / precise metro
Seems like this should be an option... I think it's a bit late to add features to 0.45 but I'll stick it on my list for later. cheers Miller On Thu, Aug 08, 2013 at 11:03:58AM +0200, Nicola Pandini wrote: Hi, I resume this old thread because I compiled pd with Miller's advices to disable MIDI buffering. I tested it with a patch (attached) and this configuration: vkeyb-MidiOUT(ch1) - pd-MidiIN pd-MidiOUT - pd-MidiIN so, every time I play a note, I see how much time it takes to pass through pd. I made this test because in my configuration I place pd between my MIDI devices and synth, samplers, etc. The first thing I noticed is that the latency no longer depends on JACK buffer(frames/period), even with the -jack startup flag, and the results are: - With the -jack flag, the latency was always 1.45ms - With the -noaudio flag, the latency was 0ms (sometimes 1.45ms) Just to compare with the standard pd, the best result I achieved is 1.45/2.9ms with -noaudio. Nicola Il 27/11/2012 18:50, Miller Puckette ha scritto: I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time = midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time = logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 96 143 300 152 10; #X obj 79 68 timer; #X obj 79 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 79 88 nbx 10 30 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 20 -262144 -1 -1 1.45125 256; #X obj 106 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 1 90 noteout 3; #X obj 106 3 notein 3; #X obj 1 2 notein 1; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 3 0 0 1; #X connect 5 0 3 0; #X connect 6 0 1 0; #X connect 6 0 4 0; #X connect 6 1 4 1; ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
Thanks - it looks like my attempts to 'git push' somehow stopped working June 1. I don't know where my new 'push' attempts are going but had better try to g3figure this one out. Meanwhile just grab from webpage. cheers Miller On Sun, Aug 18, 2013 at 10:49:06AM +0200, Funs Seelen wrote: Hi Miller, Thanks for the new features! On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git:// pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test It seems to me that there is no tag or branch named 0.45-.. available. user@desktop:~/git/pure-data$ git checkout 0.4 0.41-0test06 0.43 0.43-2 0.43-4 0.44-0test2 0.42 0.43-1 0.43-2test10.43-test1 0.44-1 0.42-4 0.43-1test30.43-3 0.44-0 0.44-3 0.42-5 0.43-1test40.43-3test10.44-0test1 Kind regards, Funs ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
OK... attempted fix in place. I don't understand the automake system so this might take an iteration or 2. thanks M On Sun, Aug 18, 2013 at 11:58:33AM +0200, Jack wrote: Le 18/08/2013 03:51, Miller Puckette a écrit : Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Some new features: binary netsend/netreceive (so you should no longer need an extern for OSC) pd~ (multiprocessing) works on windows and is less likely to deadlock although not yet perfect multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. texts are also avaioable as fields in data structures. tempo messages for delay, metro, timer, and test sequence. In particular you can specify or measure time in samples, but you can also use this for changing the speed of an ensemble of delay loops while keeping them in sync. Objects/messages/comments have settable box widths. Also various improvements in audio and midi handling: The Pd window now tells you whether PD has an audio device open or not Fixed hangups exiting when using jack Got ASIO working again on PC (it was apparently broken; I don't know for how long.) cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Hello Miller, I get errors after : $ sudo make install ... make install-data-hook make[5]: Entering directory `/home/jack/Téléchargements/pd-0.45-0test1/extra/expr~' cd /usr/local/lib/pd/extra/expr~ ( \ ln -s expr~.pd_linux expr.pd_linux; \ ln -s expr~.pd_linux fexpr~.pd_linux; \ cd ..; \ ln -s expr~/expr.pd_linux expr.pd_linux; \ ln -s expr~/expr~.pd_linux expr~.pd_linux; \ ln -s expr~/fexpr~.pd_linux fexpr~.pd_linux; \ ln -s expr~/expr-help.pd expr-help.pd; \ ln -s expr~/expr-help.pd expr~-help.pd; \ ln -s expr~/expr-help.pd fexpr~-help.pd; \ ) ln: failed to create symbolic link ‘expr.pd_linux’: File exists ln: failed to create symbolic link ‘fexpr~.pd_linux’: File exists ln: failed to create symbolic link ‘expr.pd_linux’: File exists ln: failed to create symbolic link ‘expr~.pd_linux’: File exists ln: failed to create symbolic link ‘fexpr~.pd_linux’: File exists ln: failed to create symbolic link ‘expr-help.pd’: File exists ln: failed to create symbolic link ‘expr~-help.pd’: File exists ln: failed to create symbolic link ‘fexpr~-help.pd’: File exists make[5]: *** [install-data-hook] Error 1 make[5]: Leaving directory `/home/jack/Téléchargements/pd-0.45-0test1/extra/expr~' make[4]: *** [install-data-am] Error 2 make[4]: Leaving directory `/home/jack/Téléchargements/pd-0.45-0test1/extra/expr~' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/home/jack/Téléchargements/pd-0.45-0test1/extra/expr~' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/jack/Téléchargements/pd-0.45-0test1/extra' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/jack/Téléchargements/pd-0.45-0test1' make: *** [install] Error 2 My system : Ubuntu 13.04 Linux jack-GE60-0NC-0ND 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ++ Jack ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
right you are... fixed. chanks M On Sun, Aug 18, 2013 at 12:08:36PM +0200, Jack wrote: Le 18/08/2013 03:51, Miller Puckette a écrit : Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Some new features: binary netsend/netreceive (so you should no longer need an extern for OSC) pd~ (multiprocessing) works on windows and is less likely to deadlock although not yet perfect multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. texts are also avaioable as fields in data structures. tempo messages for delay, metro, timer, and test sequence. In particular you can specify or measure time in samples, but you can also use this for changing the speed of an ensemble of delay loops while keeping them in sync. Objects/messages/comments have settable box widths. Also various improvements in audio and midi handling: The Pd window now tells you whether PD has an audio device open or not Fixed hangups exiting when using jack Got ASIO working again on PC (it was apparently broken; I don't know for how long.) cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Re-hello Miller, In your help patch about [delay], when you write about 'tempo' : In this example the unit is set to 1/2 millisecond so that '1000' gives a delay of 2000 msec (2 seconds). This should give a 500 ms instead 2000 ms, or i am wrong ? ++ Jack ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
Hi Katya - Most likely the 'list' trouble is it has a 'del' object - here's the fix: --- a/src/x_time.c +++ b/src/x_time.c @@ -127,8 +127,7 @@ static void delay_setup(void) delay_class = class_new(gensym(delay), (t_newmethod)delay_new, (t_method)delay_free, sizeof(t_delay), 0, A_DEFFLOAT, A_DEFFLOAT, A_DEFSYM, 0); -class_addcreator((t_newmethod)delay_new, gensym(del), -A_DEFFLOAT, , A_DEFFLOAT, A_DEFSYM, 0); +class_addcreator((t_newmethod)delay_new, gensym(del), A_DEFFLOAT, 0); class_addbang(delay_class, delay_bang); class_addmethod(delay_class, (t_method)delay_stop, gensym(stop), 0); class_addmethod(delay_class, (t_method)delay_ft1, (which I'll put in test 2 later but you can patch it now if you don't want to wait :) The business of sharing [text] borrows ideas from the design of [delwrite~] but also (in being able to operate anonymously through pointers) from Krzysztof Czaja's very ahead-of-its-time design for the [xeq] object. cheers Miller On Sun, Aug 18, 2013 at 12:44:56PM +0200, katja wrote: Hi Miller, That's a lot of new, very useful features! It is really cool to have a decent text editor within Pd. I like how methods on named [text] and [array] objects can be called from any place (depending on scope), since you can get output where you want it instead of everything coming from one outlet. Therefore [text] is more powerful than [cyclone/coll] indeed. Wasn't Jonathan Wilkes proposing a similar approach for glists in general some time ago? I compiled Pd 0.45-0test1 on Xubuntu 10.4. I'm sorry to report the following: if the help patch for [list] is opened, Pd exits with 'Segmentation fault (core dumped)'. Katja On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Some new features: binary netsend/netreceive (so you should no longer need an extern for OSC) pd~ (multiprocessing) works on windows and is less likely to deadlock although not yet perfect multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. texts are also avaioable as fields in data structures. tempo messages for delay, metro, timer, and test sequence. In particular you can specify or measure time in samples, but you can also use this for changing the speed of an ensemble of delay loops while keeping them in sync. Objects/messages/comments have settable box widths. Also various improvements in audio and midi handling: The Pd window now tells you whether PD has an audio device open or not Fixed hangups exiting when using jack Got ASIO working again on PC (it was apparently broken; I don't know for how long.) cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
Can you remind me what OS and audio hardware you're on? (I tested this on Windows XP / ASIO4ALL but clearly I need to figure out how to test other configurations somehow.) cheers Miller On Sun, Aug 18, 2013 at 03:25:09PM +0200, Colet Patrice wrote: Le 18/08/2013 03:51, Miller Puckette a écrit : Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Got ASIO working again on PC (it was apparently broken; I don't know for how long.) I've got ASIO working only from cmd: pd -asio Great! Thanks a lot! When I start pd (without -asio) and choose ASIO in GUI menu it's still stucking, cheers, PatCo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
Yep - I need to update pointer's help file to mention text items in scalars - meanwhile the magic is described in the [text] help file. But there's a bug report out already (don't hit the '0' message :) I'm planning to make a way for the 'pointer' object to delete individual scalars but can't decide yet between two possible ways of doing it :) M On Sun, Aug 18, 2013 at 08:47:36PM +0100, João Pais wrote: multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. great, that's really nice. texts are also avaioable as fields in data structures. is it possible to update [pointer] or other object's help files to know how? or send an example patch? Can texts be used as lists in data structures? I noticed the new scalar object. Is it also supposed to edit already existing scalars? Can it have a delete function, which can yet only be done in edit mode or by deleting the whole canvas? Besides adding an important feature to the program, it also prevents something that happens now and then: some scalars can become trapped inside a patch, without the user knowing about it, if they aren't being displayed somewhere. The only way to detect and delete these orphan scalars would be by editing the patch file in a text editor. Best, João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
It's confusing -- portaudio is configured to allow either MMIO or ASIO. I'm thinking about taking the MMIO stuff out since it's already covered in the other API option. But I can't help worrying that PA's MMIO implementation will work for some cases that mine won't. Meanwhile I'll put in a hack to improve clarity at least. Sounds like I migth be able to get this to fail on my end just by repeatedly turning DSP and ASIO on and off... I'll try that as soon as I can stomach booting my old Windows box again :) M On Sun, Aug 18, 2013 at 09:49:42PM +0200, Colet Patrice wrote: RME fireface is plugged on my Dell Studio 1557 laptop, on Windows Vista, there are also ASIO from cubase and ASIO4ALL. If I start pd -asio and turn DSP on without selecting ASIO drivers, it freezes, at the same time I wonder why other devices than ASIO are appearing in listdev, the freeze might be caused because PA is using wrong driver 'pd -asio -listdev' shows in console: audio input devices: 1. (0)Mappeur de sons Microsoft - Input 2. (0)Microphone / Ligne entree (IDT 3. (0)Analog (3+4) (RME Fireface 400) 4. (0)Reseau de microphones (IDT High 5. (0)ADAT (5+6) (RME Fireface 400) 6. (0)Analog (7+8) (RME Fireface 400) 7. (0)Analog (5+6) (RME Fireface 400) 8. (0)SPDIF (RME Fireface 400) 9. (0)ADAT (1+2) (RME Fireface 400) 10. (0)Analog (1+2) (RME Fireface 400) 11. (0)ADAT (7+8) (RME Fireface 400) 12. (0)ADAT (3+4) (RME Fireface 400) 13. (1)ASIO Fireface 14. (1)ASIO4ALL v2 15. (1)Generic Low Latency ASIO Driver audio output devices: 1. (0)Mappeur de sons Microsoft - Output 2. (0)Haut-parleurs (RME Fireface 400 3. (0)Analog (3+4) (RME Fireface 400) 4. (0)ADAT (7+8) (RME Fireface 400) 5. (0)SPDIF (RME Fireface 400) 6. (0)Analog (5+6) (RME Fireface 400) 7. (0)ADAT (1+2) (RME Fireface 400) 8. (0)ADAT (3+4) (RME Fireface 400) 9. (0)Haut-parleurs / Casque (IDT Hig 10. (0)Analog (7+8) (RME Fireface 400) 11. (0)ADAT (5+6) (RME Fireface 400) 12. (1)ASIO Fireface 13. (1)ASIO4ALL v2 14. (1)Generic Low Latency ASIO Driver Le 18/08/2013 21:34, Miller Puckette a écrit : Can you remind me what OS and audio hardware you're on? (I tested this on Windows XP / ASIO4ALL but clearly I need to figure out how to test other configurations somehow.) cheers Miller On Sun, Aug 18, 2013 at 03:25:09PM +0200, Colet Patrice wrote: Le 18/08/2013 03:51, Miller Puckette a écrit : Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Got ASIO working again on PC (it was apparently broken; I don't know for how long.) I've got ASIO working only from cmd: pd -asio Great! Thanks a lot! When I start pd (without -asio) and choose ASIO in GUI menu it's still stucking, cheers, PatCo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
OK... looks like you can git-clone it as follows: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data \ pure-data-pure-data cd pure-data-pure-data git checkout HEAD I don't know why it's now called 'pure-data-pure-data' nor how to give it a simpler name. Astonishingly, one can still apparently check out 'pure-data' instead of 'pure-data-pure-data' and one gets an old version; I'd love to be able to delete that or consolidate teh two somehow, but am afraid to try. cheers Miller Hi Miller, Thanks for the new features! On Sun, Aug 18, 2013 at 3:51 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git:// pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test It seems to me that there is no tag or branch named 0.45-.. available. user@desktop:~/git/pure-data$ git checkout 0.4 0.41-0test06 0.43 0.43-2 0.43-4 0.44-0test2 0.42 0.43-1 0.43-2test10.43-test1 0.44-1 0.42-4 0.43-1test30.43-3 0.44-0 0.44-3 0.42-5 0.43-1test40.43-3test10.44-0test1 Kind regards, Funs ___ 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
Re: [PD] [PD-announce] pd 0.45 test release
OK .. this and Jaime's other report (x labels not updating when resize table using [array size] should now be fixed in git (to appear in 'test 2 later - first I want to look at ASIO some more) cheers Miller On Sun, Aug 18, 2013 at 08:47:34PM +0100, João Pais wrote: When testing the text and data structures example, when clicking on the 0 message, Pd freezes in OSX 10.7.5. same in W7 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
I'll check - if they look safe I'l lthrow them in. cheers M On Mon, Aug 19, 2013 at 04:45:48AM +0200, IOhannes m zmölnig wrote: great news. i'm currently more or less offline, so i couldn't really have a closer look yet. in the meantime, would it be possible to do a quick check on the patches used for the Debian packages [1], and see which ones should be included upstream as well? i'll be flying back from australia today, and once i'm there i can hopefully suggest more specific patches to be included (for now i mainly don't want to miss the window-of-opportunity). fgmasdr IOhannes [1] http://sources.debian.net/src/puredata/0.44.3-1/debian/patches ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45 test release
OK... I left these ones out: pd2puredata.patch usrlibpd_path.patch fixmanpage.patch helpbrowser_puredata-doc.patch since I think they're debian-specific; took the other 11. Thanks - they look helpful! On Sun, Aug 18, 2013 at 08:21:21PM -0700, Miller Puckette wrote: I'll check - if they look safe I'l lthrow them in. cheers M On Mon, Aug 19, 2013 at 04:45:48AM +0200, IOhannes m zmölnig wrote: great news. i'm currently more or less offline, so i couldn't really have a closer look yet. in the meantime, would it be possible to do a quick check on the patches used for the Debian packages [1], and see which ones should be included upstream as well? i'll be flying back from australia today, and once i'm there i can hopefully suggest more specific patches to be included (for now i mainly don't want to miss the window-of-opportunity). fgmasdr IOhannes [1] http://sources.debian.net/src/puredata/0.44.3-1/debian/patches ___ 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
[PD] [PD-announce] pd 0.45 test release
Hi all, Pd 0.45-0test1 is now up on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data git checkout 0.45-0test1 Some new features: binary netsend/netreceive (so you should no longer need an extern for OSC) pd~ (multiprocessing) works on windows and is less likely to deadlock although not yet perfect multi-purpose array and text objects. Array is a more general replacement for the table, tabread and tabwrite obejcts. text is sort of like Max's coll but simpler and hopefully more powerful. texts are also avaioable as fields in data structures. tempo messages for delay, metro, timer, and test sequence. In particular you can specify or measure time in samples, but you can also use this for changing the speed of an ensemble of delay loops while keeping them in sync. Objects/messages/comments have settable box widths. Also various improvements in audio and midi handling: The Pd window now tells you whether PD has an audio device open or not Fixed hangups exiting when using jack Got ASIO working again on PC (it was apparently broken; I don't know for how long.) cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
I believe it should not happen ($1-loop would expand to different symbols depending on $1). cheers M On Sat, Aug 10, 2013 at 11:23:19AM -0400, Jonathan Wilkes wrote: On 08/10/2013 10:37 AM, Jonathan Wilkes wrote: On 08/09/2013 08:01 PM, Miller Puckette wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. So the problem doesn't happen with [s $0-loop]? I mean [r $0-loop] -Jonathan -Jonathan cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ 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 ___ 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 ___ 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
Re: [PD] [PD-dev] portaudio callback problem [WAS:Re: PA_Terminate]
Hi Patrice - I actually don't have any working ASIO devices which makes it hard for me to figure out what's wrong here. I'll make another attemot to get something installed in the next week or so. Meanwhile, am I reading this right that you get different results depending on whether you put the -asio flag before or after the -audioindev 13 -audiooutdev 12 ? I don't know why that would happen. cheers Miller On Sat, Jul 27, 2013 at 03:46:49AM +0200, Colet Patrice wrote: Le 27/07/2013 00:39, Colet Patrice a écrit : Hello, I'm trying to find out why portaudio doesn't work with my windows machine. pd doesn't stuck anymore if I put Pa_Terminate() at the end of function static void pa_init(void) in s_audio_pa.c I don't understand why Pa_Terminate() is not used anymore, it's under comments in function int pa_open_audio() because by reading http://portaudio.com/docs/v19-doxydocs/initializing_portaudio.html, I see that this function must be used. It doesn't matter anymore because I've partly resolved the problem, and it partly comes from portaudio... If pa_process.c has been modified like explained in following link: http://music.columbia.edu/pipermail/portaudio/2012-December/014649.html audioindev audiooutdev can be forced before declaring asio like this: pd -audioindev 13 -audiooutdev 12 -asio Then It's possible to know which device to use with this command: pd -audioindev 0 -audiooutdev 0 -asio -listdev I hope someone can rewrite PaError pa_open_callback(...) in s_audio_pa.c because all those problems mainly comes from this function, and asio will certainly work better for everyone. My guess would be about making sure that p_instreamparams and p_outstreamparams aren't NULL before starting pa_stream. cheers, PatCo ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi Miller, Just very generally BTW: Do you mean binary compatibility or patch compatibility? Either way, what are your thoughts about the possibility of a future Pd-1.0 which would break (some kind of) compatibility for the sake of revolutionary progress? András I'm unwilling to break either patch or binary compatibility - Pd's original purpose is for interactive music and art and there is a big repertory now depending on Pd to remain runnable. I'm willing to make minor compatibility changes protected by compatibility switches. Pd now maintains a global compatibility version number to try to facilitate this. (It was necessitated by two bugs in DSP objects, one rather serious, that I wanted to fix without breaking old patches that might depend on the buggy behavior.) On a side note, the reason I'm so slow to add fetures to Pd is that I want to be sure that everything I do is something I'm willing to maintain for as long as I can. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
There still could be situations where an abstraction has a sub-patch (pd foo
for instance) - I'm not clear as to whether those namings should be supressed
as well. It seems like a tricky problem - lots of people seem to use
abstractions with only one instance and might be depending on the bindings.
Maybe the rule should be that before a canvas binds itself to the symbol
it checks to see if anyone else already did and if so silently refuses
(protected with a compatibility flag as usual).
cheers
M
On Fri, Aug 09, 2013 at 03:15:52PM +0100, Claude Heiland-Allen wrote:
Hi,
On 09/08/13 04:27, Miller Puckette wrote:
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, pd-name. Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 (test) compiled 17:10:02 Aug 8 2013
patch bench opendsp saveclose
small 4.6e-05 38.775 1.34085 44.326 4.012
medium 5.2e-05 314.812 10.2582 715.956 144.512
large 4.7e-05 2639.28 85.3561 78711.5 35918
git master, lightly patched with the attached
Pd-0.45.0 (test) compiled 14:36:39 Aug 9 2013
patch bench opendsp saveclose
small 4.3e-05 36.167 1.31707 39.657 3.447
medium 4.4e-05 291.52 9.8958 327.389 18.067
large 4.3e-05 2443.07 82.0808 3628.66 224.972
There's a good reason to bind toplevels and named sub-patches to ther names,
but I think there's little reason to do it for abstractions - perhaps I can
take this out, but I'd have to leave it as an option for compatibility
(ouch!)
The attached patch doesn't do this, but it should be easy to add a
global compatibility flag to the new canvas_should_bind() function.
Toplevel patches are still bound to pd-name.pd and subpatches [pd
name] are still bound to pd-name; it's just abstraction instances
that no longer have the automatic binding.
On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
[snip]
The killer in the bottom right corner: with 8x as many abstractions, it
takes 100x as long to save an instance, and 200x as long to close the
patch.
[snip]
Any idea why save is so much greater than close + open?
I think Miller had the answer.
Also, any idea what pd is doing for the bulk of that time when
I haven't profiled yet (I had trouble even getting debug symbols into an
installed Pd with the autoconf system, no success yet..), so the
following are just guesses:
saving
searching for copies of the abstraction to reload, then reloading them
via some select/cut/undo method (which preserves connections). also
unbinding symbols...
closing
calling all the destructors. also unbinding symbols...
opening
refinding/reloading/reparsing/reinstantiating all the abstractions (I
need to relocate my abstraction cache patches and update them to current Pd)
dsp'ing?
traversing each canvas to topologically sort its dsp objects and build
the dsp chain - which gets resizebytes() each time something is added,
could make it O(log(N)) count of resizes (doubling the size each time)
but I tried it and it saved about 9 microseconds, not worth the extra
complexity...
Claude
--
http://mathr.co.uk
From 16fd46b3abe83dba956b78385d01ad19737b6c76 Mon Sep 17 00:00:00 2001
From: Claude Heiland-Allen cla...@mathr.co.uk
Date: Fri, 9 Aug 2013 14:57:14 +0100
Subject: [PATCH] don't bind abstraction instances to pd-filename
---
src/g_canvas.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/src/g_canvas.c b/src/g_canvas.c
index 804ac57..c7a22d6 100644
--- a/src/g_canvas.c
+++ b/src/g_canvas.c
@@ -55,6 +55,9 @@ void canvas_reflecttitle(t_canvas *x);
static void canvas_addtolist(t_canvas *x);
static void canvas_takeofflist(t_canvas *x);
static void canvas_pop(t_canvas *x, t_floatarg fvis);
+static int canvas_should_bind(t_canvas *x);
+static void canvas_bind(t_canvas *x);
+static void canvas_unbind(t_canvas *x);
/* - functions to handle the canvas environment --- */
@@ -205,11 +208,9 @@ void canvas_makefilename(t_canvas *x, char *file, char
*result, int resultsize)
void canvas_rename(t_canvas *x, t_symbol *s, t_symbol *dir)
{
-if (strcmp(x-gl_name-s_name, Pd))
-pd_unbind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_unbind(x);
x-gl_name = s;
-if (strcmp(x-gl_name-s_name, Pd))
-pd_bind(x-gl_pd, canvas_makebindsym(x-gl_name));
+canvas_bind(x);
if (x-gl_havewindow)
canvas_reflecttitle(x);
if (dir dir != s_)
@@ -379,8 +380,7 @@ t_canvas *canvas_new(void *dummy, t_symbol *sel, int
argc, t_atom *argv)
x-gl_owner = owner;
x-gl_name = (*s-s_name ? s :
(canvas_newfilename ? canvas_newfilename : gensym(Pd
Re: [PD] abstraction penalty benchmarks
Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ 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
Re: [PD] abstraction penalty benchmarks
Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ 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 ___ 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
Re: [PD] abstraction penalty benchmarks
Here's a guess - I think each copy of the abstraction binds itself to a symbol, pd-name. Binding is fast bt unbinding is linear-time in the number of things bound to the symbol... ouch. There's a good reason to bind toplevels and named sub-patches to ther names, but I think there's little reason to do it for abstractions - perhaps I can take this out, but I'd have to leave it as an option for compatibility (ouch!) Miller On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote: On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote: Hi, Today I remembered one performance where I saved an abstraction with many instances, bringing things to a halt. So I benchmarked this scenario and some similar ones - some seem to scale very badly. pure-data.git gcc-4.8.1 GNU/Linux/Debian/Wheezy amd64 64bit Pd-0.45.0 (test) compiled 17:10:02 Aug 8 2013 m n open dsp save close 351238.503 1.33879 44.26 3.985 4 4096 324.507 10.7379 786.227150.602 5 32768 2611.92 85.40579234.235853 keydescription m number of levels of nested abstractions n total number of instances at deepest level open time to load patch dsptime to toggle dsp on then off (1000 runs averaged) save time to save one instance at deepest level close time to close patch all times are in ms, measured with [realtime] rows run sequentially in their own pd instance dsp was off at the start of each test the whole run is in zero logical time cpu frequency scaling was disabled (for real) pd was run with -nogui -nosound -nrt The killer in the bottom right corner: with 8x as many abstractions, it takes 100x as long to save an instance, and 200x as long to close the patch. See attached tarball if you want to try it yourself. Thanks for the stats. Any idea why save is so much greater than close + open? Also, any idea what pd is doing for the bulk of that time when saving, closing, opening, and dsp'ing? -Jonathan Claude ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change #define HASHSIZE 1024 to #define HASHSIZE 65536 or so, recompile and see if that makes it run faster. (Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?) cheers Miller On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote: Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Oops, sorry - I think I'm leading you astray - it might take a long time to figure out how to patch sources adn recompile Pd if you aren't already habituated to compiling software. Anyway, I don't really know that it's gensym() that's taking the 6% of your processor - that's just a guess. So I'm not sure what to try next... Miller On Wed, Aug 07, 2013 at 05:23:16PM -0300, Mario Mey wrote: Oh... *compile*... I'm afraid of that word. Once (during some days), I tried to compile Pd... but with no good results. I will try to download the source, look for a easy-to-compile tutorial... but, if it takes me so much time, I think I'll go on with the current version of PdExt (0.43.4). Maybe I will try it later... or later... or even more later. To profile Pd, is there an option in my version, or I have to change code, like #define PROFILE 1? Cheers. El 07/08/13 16:53, Miller Puckette escribió: Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change #define HASHSIZE 1024 to #define HASHSIZE 65536 or so, recompile and see if that makes it run faster. (Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?) cheers Miller On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote: Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. cheers Miller On Wed, Aug 07, 2013 at 02:05:45AM +0100, Ed Kelly wrote: There is another catch with the CPU usage, which I only learned about while building a big libpd app. If you have subpatches within subpatches this is usually not a problem with control data. But, it really helps a lot within a patch if you put all the DSP objects on the same layer (i.e. without and audio subpatches). Of course, the most CPU efficient patch will have no audio subpatches at all. I think the reason is that subpatch audio is calculated in a block within the subpatch, and this means a separate process from the master patch and takes more CPU time. I'm not 100% sure that's the case, but intuitively it seems to make sense. Cheers, Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Mario Mey mario...@gmail.com To: J Oliver jaime.oliv...@gmail.com Cc: pd-list@iem.at Sent: Tuesday, 6 August 2013, 3:15 Subject: Re: [PD] How to reduce CPU use on unused subpatches-abstracts? Hi, J. Thanks for the response. Following some suggestion (from you, Maelstorm, Servando Barreiro), I made some tests. I took the dare to post your mail in the thread... maybe it's better to post there, if anyone has the same problem or just wants to learn. Here is the thread: http://puredata.hurleur.com/viewtopic.php?pid=37895 I answer your mail right there. Could you take a look? Anyway, as I writed there, I WILL CHECK IT AGAIN, AND I WILL DO SOME OTHER TESTS. El 05/08/13 10:36, J Oliver escribió: Hi Mario, There is a thread somewhere about connections vs. s/r throw/catch, don't have time right now to search for it, but I'm sure it is there. If I remember correctly the overhead is not that big and you don't want to be connecting all that stuff by hand. In any case, there are other things to look for. If you are using graphics objects, or objects like env~ you might want to bring down the refresh rate. Are there any [metro 1] or similar objects lying around which you might have forgotten about? Do you have a lot of GOP? I am not sure this is entirely relevant, but it might be worth researching... Also, control operations do take some cpu. do you have a big control layer? J Thanks, Roman, but I'm already using [switch~] inside each FX, to stop processing the signal. I learned it some time ago, from here: http://puredata.hurleur.com/viewtopic.php?pid=35939#p35939 But I think that [receive~] and [throw~] are still using CPU. I didn't try to use inlet~ and outlet~, because I have to make 400 conections at hand... that's why I asking first. If it will work, I'll do it (or find a way to automatically do it) El 05/08/13 09:29, Roman Haefeli escribió: Hi Mario Check [switch~] and its help patch. Roman On Mon, 2013-08-05 at 09:03 -0300, Mario Mey wrote: Hi, there... I really need some help. I'm working on a looper-multi-effects (big) patch. It has more than, more or less, 100 stereo FXs. They are all inside the patch as abstracts. But, to avoid them to consume CPU, each one has a [switch~ 0] if it is not working. So, there're only two FX at a time, where the DSP is on. Something like this: Main patch: adc~ | \ | [s $0-pre-r] [s $0-pre-l] [catch~ $0-post-l] | [catch~ $0-post-r] | / [dac~] (the same for Each FX as file-abstracts (using [fx1 $0] to call them) inside the main patch: [r $1-pre-l] [r $1-pre-r] | / [The-FX-itself.] | \ [throw~ $1-post-l] [throw~ $1-post-r] [0( [1( | / [switch~] This technics DOES work very well. Buuut... when having 100 FX at the same time (even not working), the CPU increase 15-20%. I repeat, there're only two FX working at the time. The rest are turned-off. For now, the CPU use is: Ready-to-use, 2 FXs on, DSP on: 47% Recorded and playing 8 stereo-banks, 2 FXs being used, DSP on: 60 - 62% (I have quite a few XRUNS) Ready-to-use, 2 FXs on, DSP off: 7% As you can see, the non-signal processing is very low. What I think is that each FX is working when receiving and/or throwing signal (200 [receive~] and [throw~] objects)... even they are sending and/or processing nothing. Is there any other way to connect all the FXs to the
Re: [PD] CPU usage of GUI objects in subpatches
I tried this with four versions of a subpatch, one with nothing (just an inlet connected through to an outlet), one with a float, one with hslider, and one with a number box (not number2, just control-3 number). Subtracting out the control case, I sent 100 random numbers through and asked the cputime object how much time elapsed, and got approximately: float hsl number closed 1050 150 open1050 150 This was usin until to loop 100times. Trying the same thing with metro 0.001 gives: closed 10 50 150 open 10 60 200 That wasn't at all what I was expecting to see! This was on a core 2 duo 7600 running at 1.6 GHz (my patch wasn't CPU hungry enough to make my CPU want to speed up), linux 3.6.3-1.fc17.x86_64 (Fedora) cheers Miller On Mon, Jul 15, 2013 at 05:18:00PM -0400, Jonathan Wilkes wrote: On 07/15/2013 09:13 AM, Frank Barknecht wrote: Hi, I didn't test current Pd versions nor your fork, but up to 0.43 GUI objects in subpatches or abstractions were a substantial and significant CPU load when they are activated, even when invisible. So this is slow: [r data] | [hsl ...] | [s data-out] But this is fast: [r data] | | [hsl ...] |/ [s data-out] Pd-l2ork version 20130528: I put a [inlet]---[hsl]---[outlet] in a subpatch and compared to a subpatch with [inlet]--[float]--[outlet]. Measuring sending a random float to each subpatch. Hsl subpatch was between 0.005 and 0.006 and float subpatch was 0.004. Measuring cpu usage with gnome-system-monitor with a [metro 1] driving the hsl subpatch: * when subpatch is un-vis'd and metro is off, cpu usage is around 15% * when subpatch is un-vis'd and metro is on, cpu usage is between 15-20% (using gnome-system-monitor so it's hard to discern the difference on the graph) * when subpatch is vis'd, cpu usage is around 60% So when the patch is vis'd, substantial and significant CPU load. When unvis'd, not so much. Debian wheezy, AMD64, pd-l2ork -Jonathan Maybe this has changed now with the latest versions, so I would recommend to benchmark it again. Ciao ___ 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
Re: [PD] Building Pd App on OSX
What I do (in effect): Get an existing Pd application and remove all the Pd sources (Contents/Resources/src, bin, doc, tcl, portaudio, portmidi, extra, *.txt) then un-tar a source tarball into Contrnts/Resources, cd to src, and make -f makefile.mac (Actually, of course, I do this from a script. I have a pre-prepared tarball of an empty Pd app, and using that and a source tarball I run this shell file: ) - #!/bin/sh #usage: ./build 0.38-0 or 0.38-0test4 if test x$1 == x then echo usage: ./build 0.38-0 or 0.38-0test4 exit 1 fi if test -d Pd-$1.app then chmod -R 777 Pd-$1.app rm -rf Pd-$1.app fi tar xzf attic/wish-shell.tgz mv Wish Shell.app Pd-$1.app cd Pd-$1.app/Contents chmod 755 . rm -f Info.plist cp -p ../../attic/Info.plist . cd MacOS chmod 755 . mv Wish Shell Pd cd .. cd Resources chmod 755 . rm -f Wish.icns cp -p ../../../attic/pd.icns ../../../attic/pd-file.icns . mv Wish Shell.rsrc Pd.rsrc tar xzf ../../../pd-$1.src.tar.gz mv pd-$1/* . rmdir pd-$1 cd src make -f makefile.mac cd .. ln -s tcl Scripts chmod 555 . .. cd ../../.. pwd chmod 755 Pd-$1.app touch Pd-$1.app chmod 555 Pd-$1.app tar czf pd-$1.mac.tar.gz Pd-$1.app cheers M On Wed, Jul 03, 2013 at 07:00:48PM -0400, Jonathan Wilkes wrote: Miller et al, Once I get Pd built on OSX, I can make install so that pd from the terminal will launch it. But how do I make it into an App? Any hints? INSTALL.txt doesn't have anything. I'd like to get it building so that a) I can make use of all the goodies someone put into AppMain.tcl and b) post a working copy so people can try out the new Preferences dialog. Separate question: even for running pd from the terminal, why doesn't the AppMain.tcl stuff get used? For example, I still want to use the OSX Preferences panel, and set all the Apple specific stuff like About Pd in the App menu, regardless of how pd was started. (Though it's not a huge deal, as the vast majority would just be running the app.) Thanks, Jonathan ___ 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
Re: [PD] Building Pd App on OSX
Yeah... I originally assembled it by trial and error, starting from the Wish Shell app and changing stuff by trial and error. It might even be the case that the Wish Shell.app archive used by the script below can be replaced with your own local one... but I thought it safer to cache copy once I had it all working. cheers M On Sat, Jul 06, 2013 at 06:08:13PM -0400, Jonathan Wilkes wrote: On 07/06/2013 05:22 PM, Miller Puckette wrote: What I do (in effect): Get an existing Pd application As in download one of your prebuilt mac binaries? -Jonathan and remove all the Pd sources (Contents/Resources/src, bin, doc, tcl, portaudio, portmidi, extra, *.txt) then un-tar a source tarball into Contrnts/Resources, cd to src, and make -f makefile.mac (Actually, of course, I do this from a script. I have a pre-prepared tarball of an empty Pd app, and using that and a source tarball I run this shell file: ) - #!/bin/sh #usage: ./build 0.38-0 or 0.38-0test4 if test x$1 == x then echo usage: ./build 0.38-0 or 0.38-0test4 exit 1 fi if test -d Pd-$1.app then chmod -R 777 Pd-$1.app rm -rf Pd-$1.app fi tar xzf attic/wish-shell.tgz mv Wish Shell.app Pd-$1.app cd Pd-$1.app/Contents chmod 755 . rm -f Info.plist cp -p ../../attic/Info.plist . cd MacOS chmod 755 . mv Wish Shell Pd cd .. cd Resources chmod 755 . rm -f Wish.icns cp -p ../../../attic/pd.icns ../../../attic/pd-file.icns . mv Wish Shell.rsrc Pd.rsrc tar xzf ../../../pd-$1.src.tar.gz mv pd-$1/* . rmdir pd-$1 cd src make -f makefile.mac cd .. ln -s tcl Scripts chmod 555 . .. cd ../../.. pwd chmod 755 Pd-$1.app touch Pd-$1.app chmod 555 Pd-$1.app tar czf pd-$1.mac.tar.gz Pd-$1.app cheers M On Wed, Jul 03, 2013 at 07:00:48PM -0400, Jonathan Wilkes wrote: Miller et al, Once I get Pd built on OSX, I can make install so that pd from the terminal will launch it. But how do I make it into an App? Any hints? INSTALL.txt doesn't have anything. I'd like to get it building so that a) I can make use of all the goodies someone put into AppMain.tcl and b) post a working copy so people can try out the new Preferences dialog. Separate question: even for running pd from the terminal, why doesn't the AppMain.tcl stuff get used? For example, I still want to use the OSX Preferences panel, and set all the Apple specific stuff like About Pd in the App menu, regardless of how pd was started. (Though it's not a huge deal, as the vast majority would just be running the app.) Thanks, Jonathan ___ 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
Re: [PD] phasor~: change freq on wraparound
that's the loop~ object in extra. cheers Miller On Thu, Jul 04, 2013 at 09:20:27PM +0200, Orm Finnendahl wrote: Hi List, sorry if I'm missing the obvious: I'd like to implement a phasor~, which only allows its frequency to be changed on wraparound. Using a samphold~ for that purpose connected to the outlet and inlet of the phasor~ doesn't work as this creates a dsp loop. I prefer a pd vanilla solution (I know how to implement it as an external, but for portability I'd like to get it done without). Any ideas? Yours, Orm ___ 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
Re: [PD] store value of any type
If it's just local, the list object will do it (floats and symbols are just one-element lists). If you want something that (like 'value') can be accessed by name or pointer elsewhere in the patch, you might want the text object (in git repo, upcoming for version 0.45). If you're insteested in trying it and don't want to compile your own write back and I can put out a test release - there's a bunch still to do but it seems to be working OK. cheers M On Thu, Jul 04, 2013 at 09:50:46PM +0200, yvan volochine wrote: hi all, I'd like to store a value which can be of any type but I don't remember if that's even possible.. something like [value foo] but that would work for integer, list, or anything else like for [foo bar 123( is there a vanilla object for that? cheers, y -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://vimeo.com/yv ___ 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
Re: [PD] store value of any type
It might be fixed. I use make -f makefile.gnu from pd/src to avoice all the automake horror, and so had allowed the automake to get out of sync witht he source - Iohannes patched that so things migth be back to normal with automake too by now. cheers M On Thu, Jul 04, 2013 at 10:08:36PM +0200, yvan volochine wrote: hi Miller, If it's just local, the list object will do it (floats and symbols are just one-element lists). If you want something that (like 'value') can be accessed by name or pointer elsewhere in the patch, you might want the text object (in git repo, upcoming for version 0.45). If you're insteested in trying it and don't want to compile your own write back and I can put out a test release - there's a bunch still to do but it seems to be working OK. I want it to be accessed by pointer somewhere else so I guess I'll give [text] a try.. thanks! y ps: pd would not build from master like 5 days ago on my machine (up-to-date archlinux) but I didn't folow recent commits so maybe that's fixed already.. -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://vimeo.com/yv ___ 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
Re: [PD] store value of any type
Aha... I never 'make install' myself - I'd better go look at that. Anyhow I think it shoud have been 'make -f makefile.gnu install' instead... cheers M On Thu, Jul 04, 2013 at 10:56:58PM +0200, yvan volochine wrote: On 04/07/13 22:54, Miller Puckette wrote: Relly - you can make a [text] object but help comes up empty? There should be a file doc/5.reference/text-object-help.pd ... nope, trying to open its help gives me: sorry, couldn't find help patch for text-object.pd and that might be because: $ ls /usr/local/lib/pd bin/ I built latest master with the following: $ cd src $ make -f makefile.gnu $ make $ sudo make install y -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://vimeo.com/yv ___ 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
Re: [PD] pd-0.45 + jack == weirdness
OK.. I made an attempt to fix the problem a diffferent (perhaps smarter) way... I made a change that migth make pd-watchdog quit more reliably when Pd exits. I believe Pd itself wil still go into zombie state waiting for its 'child' jackd to exit - and I think this is a problem in jack - but perhaps at least the watchdog will shut up :) It's up on the git repo - the mindless way to get it would be to make a new directory and clone it... git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data M On Wed, Jun 26, 2013 at 10:24:15AM -0400, Dan Wilcox wrote: A checkbox in the audio settings? [X] Autostart jack server on pd startup On Jun 26, 2013, at 8:11 AM, pd-list-requ...@iem.at wrote: From: yvan volochine yvan...@gmail.com Subject: Re: [PD] pd-0.45 + jack == weirdness Date: June 26, 2013 6:28:57 AM EDT To: pd-list pd-list@iem.at On 26/06/13 11:31, IOhannes m zmoelnig wrote: yes, i would like to have an -audio auto switch, that will try to get*any* audio backend (e.g. jack, alsa, oss, dummy; in that order) i even think that this should be the default (e.g. when you start Pd with no arguments and uninitialized settings). but please provide a way to disable this autostart-audio feature. (I don't know any audio app which starts jack for me Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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
Re: [PD] compiling pd vanilla on a mac
I find configure scripts too complicated for human understanding, and so I just use the hand-edited makefile: make -f makefile.mac, invoked from the /src directory. cheers Miller On Wed, Jun 26, 2013 at 02:47:58PM -0700, Jonathan Wilkes wrote: Hi, Any clues about this ./configure error: configure: error: Couldn't find 10.5, 10.6, or 10.7 SDK configure: error: ./configure failed for portaudio I have no clue how to check what SDK version I have installed (Google returns nothing useful) For reference: After agreeing to some stupid license agreement that I didn't read I downloaded the stupid Command Line Tools (OSX Lion) for Xcode - 2013 which claims to include the the Mac OSX SDK Frameworks and headers (which I had to type out because their stupid webpage doesn't allow you to copy/paste the stupid text). Thanks, Jonathan ___ 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
Re: [PD] pd-0.45 + jack == weirdness
Thanks... I'm toying with a middle solution, which would be simply to open jack with the JackNoStartServer option (one of JackOpenOptions). I think this is a good idea anyway as the user might want to specify jack options and it seems wrong to have Pd get involved in that. cheers Miller On Mon, Jun 24, 2013 at 11:33:47AM +0200, Ivica Bukvic wrote: Miller, I think I solved the hang part in pd-l2ork implementation that is based on the older model that allows disconnection and reconnection practically under any circumstances. The only downside is if you yank the USB soundcard while jack is running pd waits on jack to report that it lost the soundcard and stops which can take up to 20 seconds. In other words in this case it's jack that is hanging and consequently making pd hang as well but only temporarily. HTH On Jun 24, 2013 5:14 AM, yvan volochine yvan...@gmail.com wrote: hi Miller, Are you using 0.44? (I don't think 0.45 exists yet :) yeah sorry, 0.44 (pd-0.45-0-test) The only relevant thing I can find in recent commits is a change from jack_client_new() to jack_client_open() back in 2010. With apologies, here is the commit I found... commit 1022e5687bb5785904ba1b1977a9a2**9c9b6b25dc [SNIP] Is it possible this bug has been there for the last three years? (i.e. 0.43 and 0.44 would have this problem)? I just built 0.43-1 and yes the problem is there as well (weird that I never tried to open pd without jack before..). I couldn't build any older pd version (I guess I have a too recent tcl somehow) so I cannot test with 0.42 (or with the commit before the one you mentioned) let me know if I should submit an issue.. ciao, y -- http://yvanvolochine.com http://soundcloud.com/**yvanvolochinehttp://soundcloud.com/yvanvolochine http://soundcloud.com/**elgusanorojo http://soundcloud.com/elgusanorojo http://vimeo.com/yv __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list ___ 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
Re: [PD] pd-0.45 + jack == weirdness
Are you using 0.44? (I don't think 0.45 exists yet :) The only relevant thing I can find in recent commits is a change from jack_client_new() to jack_client_open() back in 2010. With apologies, here is the commit I found... commit 1022e5687bb5785904ba1b1977a9a29c9b6b25dc Author: IOhannes m zmoelnig zmoel...@iem.at Date: Wed Jul 14 10:02:45 2010 +0200 properly handle shutdown of jackd and updated to new jack API in older versions of Pd, if the jackd shut down (e.g. because the user stopped it manually), Pd would just freeze and could not be revived (you have to KILL it) properly handling the jack_shutdown signal allows us to cleanup and continue to run. the user can then select another backend at their convenience. Pd's jack-backend mainly used _deprecated_ way of interfacing with jack (namely using jack_client_new() rather than jack_client_open()) the new API allows more flexibility (e.g. the jackd need not run before the application starts - if it is missing, it will be automatically launched) TODO: jack is actually a callback-based API... Signed-off-by: Miller Puckette m...@ucsd.edu Is it possible this bug has been there for the last three years? (i.e. 0.43 and 0.44 would have this problem)? cheers Miller On Mon, Jun 24, 2013 at 01:26:50AM +0200, yvan volochine wrote: hi list! I seem to recall some changes about the way pd and jackd interact together but I couldn't find the related info online so forgive me if that was discussed already.. before, if I launched pd without jack running, pd would take more time to launch with a bunch of messages complaining that jack is not running... now, if jack is not running and I launch pd, pd starts jack by itself.. well... ok... the problem is that when I close pd, it just won't close (terminal would print watchdog... signaling pd messages forever) and unless I kill the created jackd process, the pd window would _never_ close argh. this is really annoying and looks like a regression to me.. should I submit an issue or is that a known one or was it discussed already (and I missed it)? running pd-0.45 on archlinux Linux x230 3.9.6-1-ARCH #1 SMP PREEMP ciao y -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://vimeo.com/yv ___ 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
Re: [PD] closed window not destroyed? (in l2ork, possibly in others too)
This may be related: after upgrading to Fedora core 17 (linux 3.6.3-1.fc17.x86_64) I found that, after running a patch for hours or days, just shutting DSP off sometimes freezes my machine for somewhere between 1 and about 20 seconds (I think). I had never suspended or hibernated the machine. I don't know how to debug this as the machine is frozen while it's happening :) Anyhow I don't get it on other machines so I'm suspicious it's a particularity with some range of linux kernels. Miller On Tue, Jun 18, 2013 at 10:58:41PM +0200, András Murányi wrote: Hi List, I've got used to putting my PC to sleep (aka hibernation) often lately. Now there is this behaviour of Pd that when you leave a patch open and put the computer to sleep, once it wakes up Pd will try to do everything it missed while the computer was sleeping, so the CPU goes 100% for quite a while. I suppose this is by design. What I've just noticed using l2ork is that I had closed my patch before hibernating (in order to avoid the CPU boost when waking up), put the computer to sleep for a few hours, and when i woke it up, surprisingly the 100% CPU boost still happened - with only the main window and console open. This makes me think some things are not destroyed properly when a patch is closed. Any thoughts appreciated... András ___ 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
Re: [PD] pd~ in windows
There's already code in s_inter.c dating from 1997-ish that does the windows version of a fork/exec so I really just have to go back and try to relearn it :) And now that there's reactOS (W2K compatible open source OS) I don't see any reason to hesitate supporting windows-ish stuff. These days it looks as if Apple is the new Microsoft. cheers Miller On Sun, Jun 16, 2013 at 12:39:31PM -0700, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pdlist pd-list@iem.at Sent: Sunday, June 16, 2013 12:56 PM Subject: Re: [PD] pd~ in windows Looking at this now. I notice that _pipe in windows even allows you to specify buffer size which linux and MacOS don't. It might be a major advantage. OTOH the major hassle is figuring out how to create and manage the sub-process in Windows which has no wait() function. I fear people finding dozens of marauding pd processes running around. Hm, I didn't look at that part at all. Since you're looking at this I'll revisit the topic later tonight and see if there are any other hints out there in the intersphere. Short digression-- after writing the Flext mingw build tutorial I've become much more understanding of Sevy's approach of actively not supporting Windows. I don't agree with it, as I think so much of Pd already runs adequately on Windows to warrant pd~, too, in order to offer free software to as many users as possible. But his was certainly a valid, compelling, and time-saving approach. :) -Jonathan cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd~ in windows
Looking at this now. I notice that _pipe in windows even allows you to specify buffer size which linux and MacOS don't. It might be a major advantage. OTOH the major hassle is figuring out how to create and manage the sub-process in Windows which has no wait() function. I fear people finding dozens of marauding pd processes running around. cheers Miller On Tue, May 07, 2013 at 04:39:42PM -0700, Jonathan Wilkes wrote: Hi, Not sure if I asked this yet (pd~ is a difficult search term) but there is a macro suggested here to define pipe syntax similar to unix: http://article.gmane.org/gmane.comp.gnu.mingw.user/28505/ So if it was just put in ascii mode would this make it possible to have the pd~ object in windows? Thanks, Jonathan ___ 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
Re: [PD] Data structures: no object for freeing pointers?
I find the data structure deign extremely limited and have been thinking for years about how to make it more powerful. I have a rather weak idea about alowing deletion of individual items in lists that I'm planning to try out in the run-up to the next release - not that that can help you right now. (In addition to the manifold problems that others have noted I'll add more fundamental ones: fundamentally clunky pointer mechanism difficulty of making numerically accurate changes on visual data structures (except by escaping to a text represntation ala 'properties' :) cheers Miller On Tue, Jun 11, 2013 at 03:04:10PM +0200, Patrice Colet wrote: Envoyé: Mardi 11 Juin 2013 11:25:23 Objet: Re: [PD] Data structures: no object for freeing pointers? On Die, 2013-06-11 at 11:00 +0200, Jan Baumgart wrote: I've been building a sequencer with data structs. But now I've come to a dead end, because there seems to be no object, that let's you remove structs. The only way seems to be deleting them in the gui. It's still possible to put only one pointer and then arrays on it, then you can add or delete at the last array item, or it's possible to put an id at each array element and then remove the element id to delete, then it's possible to have undo's. pc ___ 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
Re: [PD] more about DS
That's what I did too :) M On Tue, May 28, 2013 at 05:22:06PM +0200, Roman Haefeli wrote: On Die, 2013-05-28 at 13:40 +0200, João Pais wrote: when you have a point defined by a variable, afaik it's always open to user interaction. but, check the help for drawpolygon, the -x argument. I never tried it. Yeah, -x works. As mentioned by Martin, it makes the struct not report clicks anymore. I came up with another solution, somewhat similar to what Johannes posted in the previous thread. I store the position at the time of the 'click' event and use the coordinates to reset the position on 'change' events. btw, a scalar is only a unit, which can have any graphic, text, symbol usw you define in the template. for these questions it's better if you say which class of element you're using. drawpolygon, usw usw Sorry for not being clear. I was actually using [filledpolygon]. Roman Hi all Is it possible to have a scalar with a settable position, but which cannot be moved with mouse interaction? I figured I can use arrays to create grids of immutable scalars, but then I don't know how I can detect which specific element/scalar has been clicked on. Thanks, Roman ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] build Pd from source on Raspberry Pi
Actually I never use the autoget system - I just cd to src and hit 'make -f makefile.gnu'. But I think yes you ned tk8.5 devel, plus the alsa libraries (alsa-devel?) cheers M On Thu, May 23, 2013 at 09:34:45AM +0100, Julian Brooks wrote: Hello Miller, Thanks for wading in with this. Failed here in 'make' (and hope I've included all the necessary info) mv -f .deps/stdout.Tpo .deps/stdout.Plo /bin/bash ../../libtool --tag=CC --mode=link gcc -O6 -funroll-loops -fomit-frame-pointer -module -avoid-version -shared -shrext .pd_linux -L../../src -o stdout.la -rpath /usr/local/lib/pd/extra/stdout stdout.lo -lpthread -ldl libtool: link: gcc -shared -fPIC -DPIC .libs/stdout.o -L../../src -lpthread -ldl -O6 -Wl,-soname -Wl,stdout.pd_linux -o .libs/stdout.pd_linux libtool: link: ( cd .libs rm -f stdout.la ln -s ../stdout.la stdout.la ) make[3]: Leaving directory `/root/pure-data/extra/stdout' make[3]: Entering directory `/root/pure-data/extra' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/root/pure-data/extra' make[2]: Leaving directory `/root/pure-data/extra' make[2]: Entering directory `/root/pure-data' make[2]: *** No rule to make target `doc/5.reference/sublist-help.pd', needed by `all-am'. Stop. make[2]: Leaving directory `/root/pure-data' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/pure-data' make: *** [all] Error 2 Couple of (possibly dumb) questions Do I need to install tk8.5 (-dev or not)? When running './autgen.sh' Are these lines relevant: libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. Don't have enough experience with building from source to know whether it's being automagically sorted or they could do with a helping hand, or it's just not important at all? It seems to me that the build process and instructions (INSTALL.txt) have become simpler/clearer? If so, thank you. On the various RPi images I've been putting together, I have always had a go at building (more for my own satisfaction) and given up in a huff when I kept falling over at early stages. Then installing from raspbian repo's, sticking on the pre-built most recent from your site and linking to ./pd via bash. Works fine but isn't quite satisfactory somehow. Anyway. Hope we can get it going (I'm going to sit tight this time). Regards, Julian On 23 May 2013 04:09, Miller Puckette m...@ucsd.edu wrote: Looks like x_array.c and x_scalar.c were missing from the file list in Makefile.am (I just added these files) - try to update the source and recompile now... cheers Miller On Thu, May 23, 2013 at 03:03:47AM +0100, Julian Brooks wrote: Hi, Been wanting to do this for a while but it always keeps failing so could do with some tips. I have the source from git git clone git:// pure-data.git.sourceforge.net/gitroot/pure-data/pure-data Then (as it's a minimal RPi image) have installed automake (and dependencies: autoconf, autotools-dev, m4, libtool, gettext) Also added libasound2-dev and tk8.5-dev (not sure if tk required?) When running ./autogen.sh then ./configure and finally make (I ran make previously so much shorter bit before it fails. I get this: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/generated -I m4 ^[[B^[[Bautoreconf: configure.ac: tracing autoreconf: configure.ac: adding subdirectory portaudio to autoreconf autoreconf: Entering directory `portaudio' autoreconf: configure.in: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.in: tracing autoreconf: configure.in: subdirectory bindings/cpp not present autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.inand libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf: running: /usr/bin/autoconf --force autoreconf: configure.in: not using Autoheader autoreconf: configure.in: not using Automake autoreconf: Leaving directory `portaudio' libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `m4/config'. libtoolize: copying file `m4/config/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4/generated'. libtoolize: copying file `m4/generated/libtool.m4' libtoolize: copying file `m4/generated/ltoptions.m4' libtoolize: copying file `m4/generated/ltsugar.m4' libtoolize: copying file `m4/generated/ltversion.m4' libtoolize: copying file
Re: [PD] UA-25 on RPI
HI Dan - I tried and got even less far than you apparently did, and gave up. It's too bad - the UA 25 is the best USB-powered interface I've found so far. For the Pi I now use small, cheap, recent-vintage ones like the Griffin iMic. (but there are even cheaper ones :) If you have low-impedance mics, my best guess would be to use an impedance matching transformer (lo to hi) and then a PC mic (high impedance) interface. cheers M On Sat, May 04, 2013 at 10:57:35AM -0400, Dan Wilcox wrote: Howdy everyone, Anyone had luck with a Roland/Edirol UA-25 with PD on a RaspberryPi? I've gotten it working fine with output, but enabling input gives me crackles and bad cpu usage. Ideally, I want 2 in / 2 out and this audio interface has worked wonderfully with Linux on older/slower machines in the past. The RPI should have no problem spec-wise to run this with PD using only alsa ... Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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
Re: [PD] ubutu 13.04
This is anecdotal, but Max Neupert told me yesterday that he installed 13.04 on a machine and found that he could no longer run skype. Apparently the proprietary nvidia driver is to blame. So if you have nvidia graphics (no matter what kind of CPU) beware! Miller On Tue, Apr 30, 2013 at 02:35:12PM +0200, stéfan piat wrote: hello, I can confirm this bug, (intel GPU + xubuntu 13.04) but this crash occured to me not only with pd : random loggofs whith random apps (or browsing folders from thoses apps) 2013/4/30 Cyrille Henry c...@chnry.net Le 30/04/2013 14:05, me.grimm a écrit : hmmm all is ok on my 13.04 installs. but im running pd-extended ... maybe the reason? well, it's a Xorg crash.not a pd crash. do you have an intel GPU? c m On Tue, Apr 30, 2013 at 5:49 AM, Cyrille Henry c...@chnry.net wrote: hello, for ubuntu user : don't update to 13.04! on my computer and also on jack computer, pd can crash X server. when creating an object, the 4th letter typed on a object box make the screen goes black and the login screen to appear after few seconds... cheers c __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/**listinfo/pd-listhttp://lists.puredata.info/listinfo/pd-list __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list ___ 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
Re: [PD] ubutu 13.04
... so it sounds like there are at least 2 serious problems with the new ubuntu affecting several applications - maybe a bit tighter quality control is needed on their end :) M Here with (to use Intel graphics): $ skype it is OK. But with (to use NVidia): $ optirun skype Skype crash. But with Pd, it is different : Pd crash X server even with or without optirun as describe Cyrille in his previous message (when you open a big (?) patch and start to add object that contains more than 3 letters). If you start a patch from scratch, you can create several objects without problem... My configuration : Pd-0.44.3 () compiled 11:55:24 Apr 29 2013 Ubuntu 13.04 Linux jack-GE60-0NC-0ND 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ++ Jack ___ 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
Re: [PD] ESI Gigaport HD+ on RPI
I can't report about that but I have another compliant USB 1.1 interface, Edrol UA25, which I've never been able to get to work with a pi. So I think this is confirmation that that can indeed sometimes happen (if it were just one of us perhaps it could have been a fluke). cheers M On Sat, Apr 27, 2013 at 11:18:06AM +0200, Antoine Villeret wrote: hi all, someone added the ESI Gigaport HD+ as a not working sound card few days ago on http://puredata.info/docs/raspberry-pi I'm quite surprised because this sound card is USB Audio Class 1 compliant and USB spec version 1.1 compliant and also fully compatible to USB 2.0 host controllers Moreover, I had a confirmation this sound card works on Linux and it's previous version ESI Gigaport Ag works on the Pi. Thus i was thinking Gigaport HD+ will work on the RPi; Who made the test ? Could you tell me more about the setup ? (mainly if you use a USB hub or not) Cheers a -- do it yourself http://antoine.villeret.free.fr ___ 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
[PD] [PD-announce] pd 0.44-3 released
Hi All - I've released 0.44-3 (source, and compiled for Windows and Mac) - I don't have my Pi handy so will be updating the pi-compiled version later. The main update is to fix the gain of the hip~ filter, which I still had wrong. I was threatening to try also to fix largefile support for 32-bit linux installations but that ended up leading down a chain of changes that I think is too complicated to be able to do safely in a bugfix release... so I'll try to get that resolved for 0.45. Also for 0.45 (and probably my main project right now) is to expand the new text object into something that will combine the functionalities of qlist, textfile, and coll, and integrate texts into data structures. cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Changing array curves with mouse interaction
I'm not sure but I believe that's because of rounding to the nearest pixel. I don't believe Tcl/TK does any anti-aliasing, even if the underlying graphical system does. cheers Miller On Thu, Apr 18, 2013 at 12:30:55PM -0400, Billy Stiltner wrote: anyone figured out why sometimes the graph points vertically are sometimes fat and sometimes skinny? I spent the better part of the day before yesterday trying to get mouse editing to snap at integer values and also line up visually over 2 pixel high canvases that were supposed to be 1 pixel. graphing weirdness. i probably figured this out before and its probably time i move onto data structures instead of doing gui graphing tricks. On Tue, Apr 16, 2013 at 11:30 AM, Billy Stiltner billy.stilt...@gmail.comwrote: on second thought I have no clue how to get vertical more than 1 pixel points or thick lines. the example , will have to look at source On Fri, Apr 12, 2013 at 7:04 AM, Billy Stiltner billy.stilt...@gmail.comwrote: make the pixel height 2wice or more than the vertical array size if its a horizontal problem do the same with width and horizontal size On Sat, Apr 6, 2013 at 8:10 AM, Björn Eriksson miu...@gmail.com wrote: Hello list, I´ve been searching around a little about hints on how to make a mouse interaction easier in an array, but didn´t find much. Sometimes it is a bit too precise to get a grip on the curve. So my question is, can there be some ways to make this gripping a bit easier? All the best, Björn Eriksson ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd 0.44 installation problem
Hi Ricardo - I never heard of that problem before... do you have a file .../pd-/tcl/pd_connect.tcl ? That's what appears to be missing judging from the messages you're getting. cheers Miller On Fri, Apr 12, 2013 at 06:50:13PM +, Ricardo Cedeño wrote: HI, I've just tried to install pd vanilla 0.44 and everything went OK I got no error messages. But when I try to run PD I got: without Jack @linux-9xum:~ pd ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started disabling real-time priority due to missing pd-watchdog (/usr/local/bin/pd-watchdog) Error in startup script: can't find package pd_connect while executing package require pd_connect (file /usr/local/tcl//pd-gui.tcl line 26) or with Jack running inux-9xum:~ pd ALSA lib pcm_dsnoop.c:617:(snd_pcm_dsnoop_open) unable to open slave ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave Cannot lock down 86577696 byte memory area (Cannot allocate memory) disabling real-time priority due to missing pd-watchdog (/usr/local/bin/pd-watchdog) Error in startup script: can't find package pd_connect while executing package require pd_connect (file /usr/local/tcl//pd-gui.tcl line 26) I'm on Opensuse 12.3 Linux linux-9xum.site 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux Any help will be greatly appreciated Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory ___ 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
Re: [PD] pd 0.44 installation problem
... and sorry, one last question - did you build it using make -f makefile.gnu or with ./autogen.sh , etc? thanks M On Fri, Apr 12, 2013 at 08:53:16PM +, Ricardo Cedeño wrote: HI Miller, I installed from source; i couldn't find PD packages in OpenSuSE (http://software.opensuse.org) nor in packman repositories. Cheers Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 13:46:58 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com Subject: Re: [PD] pd 0.44 installation problem Thanks... did you install from source or did you find a SUSE package somewhere? I think it would be good to try to fix this :) M On Fri, Apr 12, 2013 at 08:33:39PM +, Ricardo Cedeño wrote: Miller, I uninstalled PD and reinstalled it, then I changed the file as you requested. I got: @linux-9xum:~ pd ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started disabling real-time priority due to missing pd-watchdog (/usr/local/bin/pd-watchdog) Error in startup script: couldn't read file /usr/local/tcl/pd_connect.tcl: no such file or directory while executing source [file join [file dirname [info script]] pd_connect.tcl] (file /usr/local/tcl//pd-gui.tcl line 26) Then I copied the entire folder /pd-0.44-0/tcl/ to /usr/local/ And Ps started as usual. To open the browser I had to copy pd-0.44-0/doc/, too Now I'm installing GEM I hope it goes smoothly. Thank you very much Cheers, Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 12:55:22 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com Subject: Re: [PD] pd 0.44 installation problem Hmmm.. I just realized that's the first pd-supplied package - so it's likely some problem about Pd's knowinbg what path to look for the package. That normally should be handled in the file, pkgIndex.tcl I don't know why it's thought necessary to use the package require nonsense in the first place (I didn't write any of this) I just tried replacing all the package require nonsense in pd_gui.tcl as follows: source [file join [file dirname [info script]] pd_connect.tcl] source [file join [file dirname [info script]] pd_menus.tcl] source [file join [file dirname [info script]] pd_bindings.tcl] source [file join [file dirname [info script]] pdwindow.tcl] source [file join [file dirname [info script]] dialog_array.tcl] source [file join [file dirname [info script]] dialog_audio.tcl] source [file join [file dirname [info script]] dialog_canvas.tcl] source [file join [file dirname [info script]] dialog_data.tcl] source [file join [file dirname [info script]] dialog_font.tcl] source [file join [file dirname [info script]] dialog_gatom.tcl] source [file join [file dirname [info script]] dialog_iemgui.tcl] source [file join [file dirname [info script]] dialog_message.tcl] source [file join [file dirname [info script]] dialog_midi.tcl] source [file join [file dirname [info script]] dialog_path.tcl] source [file join [file dirname [info script]] dialog_startup.tcl] source [file join [file dirname [info script]] helpbrowser.tcl] source [file join [file dirname [info script]] pd_menucommands.tcl] source [file join [file dirname [info script]] opt_parser.tcl] source [file join [file dirname [info script]] pdtk_canvas.tcl] source [file join [file dirname [info script]] pdtk_text.tcl] source [file join [file dirname [info script]] pdtk_textwindow.tcl] # TODO eliminate this kludge: source [file join [file dirname [info script]] wheredoesthisgo.tcl] source [file join [file dirname [info script]] pd_guiprefs.tcl] and things started up fine... would you give that a try on your end and see if that helps? thanks M On Fri, Apr 12, 2013 at 07:36:42PM +, Ricardo Cedeño wrote: HI Miller, yes, I do. Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 12:04:04 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] pd 0.44 installation problem Hi Ricardo - I never heard of that problem before... do you have a file .../pd-/tcl/pd_connect.tcl ? That's what appears to be missing
Re: [PD] pd 0.44 installation problem
Thanks... I don't understand that build system - perhaps someone who does will comment :) Miller On Fri, Apr 12, 2013 at 09:26:53PM +, Ricardo Cedeño wrote: I did it using ./autogen.sh, ./configure, and make install cheers, Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 14:02:03 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] pd 0.44 installation problem ... and sorry, one last question - did you build it using make -f makefile.gnu or with ./autogen.sh , etc? thanks M On Fri, Apr 12, 2013 at 08:53:16PM +, Ricardo Cedeño wrote: HI Miller, I installed from source; i couldn't find PD packages in OpenSuSE (http://software.opensuse.org) nor in packman repositories. Cheers Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 13:46:58 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com Subject: Re: [PD] pd 0.44 installation problem Thanks... did you install from source or did you find a SUSE package somewhere? I think it would be good to try to fix this :) M On Fri, Apr 12, 2013 at 08:33:39PM +, Ricardo Cedeño wrote: Miller, I uninstalled PD and reinstalled it, then I changed the file as you requested. I got: @linux-9xum:~ pd ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2223:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started disabling real-time priority due to missing pd-watchdog (/usr/local/bin/pd-watchdog) Error in startup script: couldn't read file /usr/local/tcl/pd_connect.tcl: no such file or directory while executing source [file join [file dirname [info script]] pd_connect.tcl] (file /usr/local/tcl//pd-gui.tcl line 26) Then I copied the entire folder /pd-0.44-0/tcl/ to /usr/local/ And Ps started as usual. To open the browser I had to copy pd-0.44-0/doc/, too Now I'm installing GEM I hope it goes smoothly. Thank you very much Cheers, Ricardo Cedeño Montaña Humboldt-Universität zu Berlin Institute of Cultural History and Theory Date: Fri, 12 Apr 2013 12:55:22 -0700 From: m...@ucsd.edu To: drnn_1...@hotmail.com Subject: Re: [PD] pd 0.44 installation problem Hmmm.. I just realized that's the first pd-supplied package - so it's likely some problem about Pd's knowinbg what path to look for the package. That normally should be handled in the file, pkgIndex.tcl I don't know why it's thought necessary to use the package require nonsense in the first place (I didn't write any of this) I just tried replacing all the package require nonsense in pd_gui.tcl as follows: source [file join [file dirname [info script]] pd_connect.tcl] source [file join [file dirname [info script]] pd_menus.tcl] source [file join [file dirname [info script]] pd_bindings.tcl] source [file join [file dirname [info script]] pdwindow.tcl] source [file join [file dirname [info script]] dialog_array.tcl] source [file join [file dirname [info script]] dialog_audio.tcl] source [file join [file dirname [info script]] dialog_canvas.tcl] source [file join [file dirname [info script]] dialog_data.tcl] source [file join [file dirname [info script]] dialog_font.tcl] source [file join [file dirname [info script]] dialog_gatom.tcl] source [file join [file dirname [info script]] dialog_iemgui.tcl] source [file join [file dirname [info script]] dialog_message.tcl] source [file join [file dirname [info script]] dialog_midi.tcl] source [file join [file dirname [info script]] dialog_path.tcl] source [file join [file dirname [info script]] dialog_startup.tcl] source [file join [file dirname [info script]] helpbrowser.tcl] source [file join [file dirname [info script]] pd_menucommands.tcl] source [file join [file dirname [info script]] opt_parser.tcl] source [file join [file dirname [info script]] pdtk_canvas.tcl] source [file join [file dirname [info script]] pdtk_text.tcl] source [file join [file dirname [info script]] pdtk_textwindow.tcl] # TODO eliminate this kludge: source [file join [file dirname [info script]] wheredoesthisgo.tcl] source [file join [file dirname [info script]]
Re: [PD] RE : Preferences Dialog
At the moment, Pd is hardwired so that, if one stops DSP, the audio device is closed for ASIO, MMIO, ALSA, CoreAudio, and OSS (not sure if I'm forgetting one :) but is kept open if the current API is jack. THis is done so that one doesn't lose jack connections when stopping and restarting DSP. I don't know of any other case when it's appropriate to keep the audio driver open (and, by implication, keep inputting and outputing samples) when DSP isn't running. Anyway, it can't be brought out into the GUI without changes to Pd itself. In general, I resist adding complexity whenever I can :) Miller On Sat, Apr 06, 2013 at 10:12:58AM -0700, Jonathan Wilkes wrote: From: colet.patrice colet.patr...@free.fr To: pd-list@iem.at Cc: Jonathan Wilkes jancs...@yahoo.com Sent: Saturday, April 6, 2013 8:10 AM Subject: RE : [PD] Preferences Dialog Seems cool in windows, also it would be nice in audio settings to have a checkbox stating if pd let other audio applications use the audio drivers or not, like in cubase. Is this with ASIO? I'm on Debian. With JACK its something you'd set through the JACK command line interface or a GUI like qjackctl. With ALSA I don't think you can do that without having the dmix plugin. Not sure with OSS. -Jonathan ___ 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
Re: [PD] Large File Support on Linux
No worries I'll just go crank up an old 32 bit linux box myself :) M On Sun, Mar 24, 2013 at 04:07:12PM +0100, Charles Goyard wrote: Hi Miller, Yes I am on 32bit linux. For what I understand on 64 bits Linux LFS is out of the box. The problem stands only for 32 bits hosts it seems. I can follow a branch on git and test for you if you wish. Alternatively I recall there's debian package to host a 32 bits linux in a 64 bits linux. Thanks Charles Miller Puckette wrote: OK... now I'm trying to fix the bug but I can't reproduce it. I made a 5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long) and opened and am reading it using readsf~. This is on a 64 bit linux box. Question for Charles Goyard: were you on a 32-bit linux machine? Or did you do something else besides just read the file from its beginning? ___ 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
Re: [PD] Large File Support on Linux
OK... now I'm trying to fix the bug but I can't reproduce it. I made a 5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long) and opened and am reading it using readsf~. This is on a 64 bit linux box. Question for Charles Goyard: were you on a 32-bit linux machine? Or did you do something else besides just read the file from its beginning? thanks Miller On Wed, Mar 20, 2013 at 06:20:59PM -0700, Miller Puckette wrote: I believe not - every extern that used open_bia_path0 would have to be fixed at the source level to use lseek64(), fstat64() in place of lseek() and fstat(). I can't see any way to fix this source-compatibly. I checked open64() on 32-bit Raspbian (ARM) and it worked fine - so I think it's save to say open64 exists on all modern linuxes, both 64 and 32 bit. cheers Miller On Wed, Mar 20, 2013 at 09:14:42PM -0400, Ivica Ico Bukvic wrote: Miller, Does this mean if one were not so concerned with backwards compatibility and included define you listed below in the s_path.c that this would fix the LFS issue albeit at the expense of backwards/cross-platform compatibility? Also, in Linux is open64 safe for both 32-bit and 64-bit OS variants? -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Miller Puckette Sent: Wednesday, March 20, 2013 6:46 PM To: IOhannes m zmölnig Cc: pd-list@iem.at Subject: Re: [PD] Large File Support on Linux OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do the right thing. I guess on Windows this would have to be somehow both UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the whole mes behind sys_this_and_that() variants. I thought exactly the same thing about a find_via_path routine. It seems to me that open_via_path, which tries not just to verify that the file exists but also that it can actually be opened, is perhaps working too hard; if a file that proves impossible to open is in an earlier spot on the path, the best thing might be to try and fail to open it instead of going out to another, perhaps incorrect, version of the file. Also, it could be fixed to take the path as an argument so that d_soundfile.c can call it from other threads safely (using separate copies of the path). cheers Miller On Wed, Mar 20, 2013 at 09:42:42PM +0100, IOhannes m zmölnig wrote: On 03/20/2013 18:02, Miller Puckette wrote: On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants). I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib). For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32. since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames. fgmadsr IOhannes ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing
Re: [PD] Large File Support on Linux
Never mind - it stopped after 74 seconds (instead of 450) - presumably 4GB early. But I don't believe this has anything at all to do with my using open() instead of open64() - apparently writesf~ put the wrong number in the soundfile header. cheers Miller On Sat, Mar 23, 2013 at 08:15:47PM -0700, Miller Puckette wrote: OK... now I'm trying to fix the bug but I can't reproduce it. I made a 5 GB soundfile (wave format, 60 channels, 4-bit floats, 450 seconds long) and opened and am reading it using readsf~. This is on a 64 bit linux box. Question for Charles Goyard: were you on a 32-bit linux machine? Or did you do something else besides just read the file from its beginning? thanks Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Large File Support on Linux
On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). cheers Miller On Tue, Mar 19, 2013 at 08:55:07PM +0100, Charles Goyard wrote: Hi, I am in favour of breaking binary compatibility and keeping the code simple. People that compile their externals themselves can understand and cope with it. Other people mostly won't notice. My intuition is that if the LFS project was unable to provide a transparent API in the first place, there's no reason we will be able to do anything clean. Just communicate enough about the breakage and enjoy :). Miller Puckette wrote: To answer Ico's question, the trouble I forsee is musician A gives musician B a patch, containing compiled externs - and then musician B runs it and gets a crash instead of music. Sub-optimal in my opinion :) ___ 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
Re: [PD] Large File Support on Linux
OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do the right thing. I guess on Windows this would have to be somehow both UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the whole mes behind sys_this_and_that() variants. I thought exactly the same thing about a find_via_path routine. It seems to me that open_via_path, which tries not just to verify that the file exists but also that it can actually be opened, is perhaps working too hard; if a file that proves impossible to open is in an earlier spot on the path, the best thing might be to try and fail to open it instead of going out to another, perhaps incorrect, version of the file. Also, it could be fixed to take the path as an argument so that d_soundfile.c can call it from other threads safely (using separate copies of the path). cheers Miller On Wed, Mar 20, 2013 at 09:42:42PM +0100, IOhannes m zmölnig wrote: On 03/20/2013 18:02, Miller Puckette wrote: On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants). I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib). For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32. since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames. fgmadsr IOhannes ___ 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
Re: [PD] Large File Support on Linux
I believe not - every extern that used open_bia_path0 would have to be fixed at the source level to use lseek64(), fstat64() in place of lseek() and fstat(). I can't see any way to fix this source-compatibly. I checked open64() on 32-bit Raspbian (ARM) and it worked fine - so I think it's save to say open64 exists on all modern linuxes, both 64 and 32 bit. cheers Miller On Wed, Mar 20, 2013 at 09:14:42PM -0400, Ivica Ico Bukvic wrote: Miller, Does this mean if one were not so concerned with backwards compatibility and included define you listed below in the s_path.c that this would fix the LFS issue albeit at the expense of backwards/cross-platform compatibility? Also, in Linux is open64 safe for both 32-bit and 64-bit OS variants? -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Miller Puckette Sent: Wednesday, March 20, 2013 6:46 PM To: IOhannes m zmölnig Cc: pd-list@iem.at Subject: Re: [PD] Large File Support on Linux OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do the right thing. I guess on Windows this would have to be somehow both UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the whole mes behind sys_this_and_that() variants. I thought exactly the same thing about a find_via_path routine. It seems to me that open_via_path, which tries not just to verify that the file exists but also that it can actually be opened, is perhaps working too hard; if a file that proves impossible to open is in an earlier spot on the path, the best thing might be to try and fail to open it instead of going out to another, perhaps incorrect, version of the file. Also, it could be fixed to take the path as an argument so that d_soundfile.c can call it from other threads safely (using separate copies of the path). cheers Miller On Wed, Mar 20, 2013 at 09:42:42PM +0100, IOhannes m zmölnig wrote: On 03/20/2013 18:02, Miller Puckette wrote: On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants). I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib). For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32. since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames. fgmadsr IOhannes ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Large File Support on Linux
To answer Ico's question, the trouble I forsee is musician A gives musician B a patch, containing compiled externs - and then musician B runs it and gets a crash instead of music. Sub-optimal in my opinion :) I now think that it should be OK to use open64() only in the file d_soundfile.c and only for linux - so putting at the head of the file, #ifdef __linux__ #define _LARGEFILE64_SOURCE #endif ... then, because opening soundfiles currently uses open_via_path, simply closing the file and re-opening it via open64(). There's a similar hack to open binbufs via paths in the function binbuf_read_via_canvas(). There are two other festering problems in open_via_path() that all should probably be fixed in one go by defining an updated function call: 1. externs further down the path are chosen in front of abstractions that should be taken instead; 2. open_via_path isn't thread safe - d_soundfile.c could call it at the same moment someone in the Pd thread is changing the path. This should almost never hapen but should be fixed. This is a big enough change that I think it should wait for 0.45, whereas the hack described above could go in right now as a local bug-fix. BTW I've got a couple of other bug-fixes underway; wil push to git now. cheers Miller Oe Mon, Mar 18, 2013 at 12:47:47PM -0400, Ivica Ico Bukvic wrote: the problem with that is, that s_path implements an API available for externals. if open_via_path() returns a filehandle for an LFS file, and the external has been compiled without LFS, the filehande will be incompatible. see [1] for a discussion. i guess the only clean way to solve that, is to provide a complete wrapper around the file API, so an external has functions guaranteed to work with the filehandle returned by Pd. currently there are sys_open()/sys_close() and its f*-variants. but we would need at least sys_(f)seek and sys_(f)stat, but preferrably a complete wrapper around LFS-compatible file functions [2]. all this functionality (including the handilng of UTF filenames on W32) is not really Pd-related, and could well be factored out into a separate library. Thanks for the clear explanation of the matter, IOhannes. Why not simply recompile externals after fixing s_path? Pd-extended already comes with most externals recompiled for every new release and adding legacy stuff just creates more confusion in maintaining the source down the road. In other words, FWIW and IMHO I think there is way too much effort the community is trying to pour into binary compatibility for a system that clearly begs for further enhancements in the core API. Best wishes, Ico ___ 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
Re: [PD] Large File Support on Linux
So a quick (and perhaps stupid) question - can I just use #idfef __linux__ to alias open to open64, etc? It works on my x86_64 machine and on my Raspberry Pi so I'm guessing all modern linuxes define an open64(). My main fear is that android might define __linux__ but not open64() - anyone know about that? thanks Miller On Sun, Mar 17, 2013 at 10:27:41AM +0100, IOhannes m zmölnig wrote: On 03/16/2013 23:42, Miller Puckette wrote: It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE' defined for this to work. Through 0.43 the configure script I was using was checking for this somehow (too complicted for me to understand how). Anyhow, this is a bug all right - thanks for reporting it! ... and can you tell me what OS you're on so I can check if I'm actually fixing it? it's in the source, the configure script already defines _LARGEFILE64_SOURCE (iirc) but something still fails (yea, definitely a bug) i confirmed that behaviour a few months ago on linux. fgamr IOhannes fbgmasdr IOhannes ___ 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
Re: [PD] Large File Support on Linux (was: readsf fails to read 32 bits float wav)
It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE' defined for this to work. Through 0.43 the configure script I was using was checking for this somehow (too complicted for me to understand how). Anyhow, this is a bug all right - thanks for reporting it! ... and can you tell me what OS you're on so I can check if I'm actually fixing it? thanks Miller On Sat, Mar 16, 2013 at 10:57:46PM +0100, Charles Goyard wrote: Darn, I just found there's a feature request for just that from IOhannes pending since 2007. https://sourceforge.net/tracker/index.php?func=detailaid=1638701group_id=55736atid=478073 Cheers, -- Charles Charles Goyard wrote: Hi, after some research, it seems more related to the size of the file after all. I thought the problem was 32 bits files because it worked when I converted them to 16 bits. But it was just the file size dropped under 2gb. To sum up: a file over about 2Gb fails to open. This is related to how Linux handles large files on 32 bits systems. On my test patch I get the done bang as soon as I send the start message. Reading the code, it looks like the s_path.c/sys_open() oflags is missing O_LARGEFILE support. pd-extended and pd-l2ork suffer from the same. Am I right there's no Large File Support for pd on 32 bits Linux ? If so that's a major shortcoming, and something a bit heavy to fix. Does it work out of the box on 64 bits linux ? Thanks, -- Charles Hans-Christoph Steiner wrote: Sounds like it, especially if you can reproduce it everytime. File a bug report and include as simple a patch as possible to reproduce the issue, and the soundfile. today I noticed a readsf~ (on vanilla) opening a 5 wave file containing 32 bits float audio fails silently. The doc says 4 bytes is unavailable for AIFF, but I use WAVE. The file is a 5 channels WAVE file with 5 tracks 32bits float at 48kHz. Converting the audio to 16 bits PCM works. Is that a bug ? On vanilla 0.44. ___ 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
Re: [PD] long list-building time
Hi all - I don't think there's any way to implement [list append] that doesn't require copying the list (tcl can do the append in place so doesn't have to do that). So building a list of length n requires a compute time on the order of n^2 - which gets to be problematic when n gets big. Another alternative to arrays might be textfiles - however, there aren't yet very good methods for getting the data back out of them :) Miller On Wed, Mar 13, 2013 at 09:12:51AM -0700, Jonathan Wilkes wrote: Hi list, See attached for difference between building a list of symbols through [list append] and building an array of symbols. Now, I know the ds array resizing and setting is more efficient than building out a list using [list append], but I don't understand why the [list append] takes over a minute to complete. It can't be due to symbol table stuff since I'm using the same symbol over and over. I know tcl lappend works fairly fast. Is there a way to speed up [list] stuff in Pd? -Jonathan #N struct wa array a word; #N struct word symbol s; #N canvas 588 135 450 506 10; #N canvas 0 0 450 300 word 0; #X obj 108 40 struct word symbol s; #X restore 332 25 pd word; #N canvas 0 0 450 300 wa 0; #X obj 40 40 struct wa array a word; #X restore 330 71 pd wa; #X scalar wa \; foo \; \;; #X obj 174 217 pointer; #X obj 134 300 setsize wa a; #X obj 89 335 element wa a; #X msg 62 305 symbol foo; #X obj 62 201 until; #X obj 62 161 t a b; #X msg 111 184 0; #X obj 62 235 f; #X obj 107 235 + 1; #X obj 107 257 t a a; #X obj 62 273 t b a; #X obj 62 366 set -symbol word s; #X obj 192 15 bng 33 250 50 0 empty empty do_it. 41 16 0 10 -262144 -1 -1; #X msg 174 140 traverse pd-dsresizing.pd \, next; #X obj 311 312 until; #X obj 311 282 t a b; #X msg 371 313 bang; #X obj 311 334 list append; #X obj 311 356 list append foo; #X msg 311 260 45000; #X obj 247 261 realtime; #X obj 292 165 bng 33 250 50 0 empty empty do_it. 41 16 0 10 -262144 -1 -1; #X obj 292 203 t b b b; #X floatatom 247 283 8 0 0 0 - - -; #X obj 231 88 realtime; #X floatatom 231 110 8 0 0 0 - - -; #X obj 192 53 t b b b b; #X msg 62 139 45000; #X connect 3 0 4 1; #X connect 3 0 5 1; #X connect 5 0 14 1; #X connect 6 0 14 0; #X connect 7 0 10 0; #X connect 8 0 7 0; #X connect 8 1 9 0; #X connect 9 0 10 1; #X connect 10 0 11 0; #X connect 10 0 13 0; #X connect 11 0 12 0; #X connect 12 0 10 1; #X connect 12 1 4 0; #X connect 13 0 6 0; #X connect 13 1 5 0; #X connect 15 0 29 0; #X connect 16 0 3 0; #X connect 17 0 20 0; #X connect 18 0 17 0; #X connect 18 1 19 0; #X connect 19 0 20 1; #X connect 20 0 21 0; #X connect 21 0 20 1; #X connect 22 0 18 0; #X connect 23 0 26 0; #X connect 24 0 25 0; #X connect 25 0 23 1; #X connect 25 1 22 0; #X connect 25 2 23 0; #X connect 27 0 28 0; #X connect 29 0 27 1; #X connect 29 1 30 0; #X connect 29 2 16 0; #X connect 29 3 27 0; #X connect 30 0 8 0; ___ 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
Re: [PD] wireless audio from Pd to PA system (katja)
Hi all -
It's correct that if you're using non-synchronized udio devces, soner
or later some FIFO will over- or under-flow and you'll get dropped
audio samples. But lots of people seem happy to live with this - for
instance, I believe anyone using Jacktrip for multi-site performances is
doing precisely that. (Me too - at home, for driver-ish reasons, I have
to use one audio device for input and a different one for output, and
no way to sync them).
If the clocks in question are accurate to a part in a million you'll get
1 msec of slip every 20 minutes or so. And a well-designed audio driver
could even see the trouble coming and do a quick cross-fade when necessary,
or choose a moment of silence to resynchronize every 10 minutes or so.
And/or, one could actually resample things. I believe this is how
Cobranet (one of the 'professional' solutions) does it. Resampling does
add a few msec of latency if done at 44K1 or 48K, but if you run at higher
rates (and if you don't mind non-flat frequency responses above 20kHz) I
believe you can do much much better, around 0.1 msec. I remember hearing a
good paper on this at the 2012 LAC (Stanford).
cheers
Miller
On Wed, Mar 06, 2013 at 01:51:12PM +0100, Pierre-Olivier Boulant wrote:
Hi Katja,
Regarding all this with...
Digital clocks need to be synchronized to work together or else you
will get clicks. As you have said it can be done in a driver or it
can be done on-chip if your hardware has that feature. It does
indeed add to the latency. On pro sound cards you would find word
clock to sync cards together or possibly time code input/output for
synchronising with video cameras. Consumer hardware does not have
these features since most people wouldn't have any use for this.
Some equipment can hold a very stable clock even after being
disconnected from the others. This feature comes with added costs.
Super expensive digital radio mics have a noticeable latency even
though they are highly specialised equipment built to minimise this
very latency. It's about 3ms for a good setup.
Anyhow the lowest latency you will find is using analog wireless
packs. The only point of digital radio mics is Hollywood can't
probably cope with non-encrypted dialogues of your favourite TV
series during the shoot.
Don't go for the cheapest, and you might not need the high end. You
can rent that stuff if it's not needed for such a long time.
The Sennheiser e100 (gen3) is pretty decent for the price. That
would be about 450~500€ for a kit.
There is a pro level audio-over-ethernet distribution system called
ethersound. It's proprietary, but worth looking into. As with other
digital format, there is a master clock somewhere in the system to
which every one syncs. Once again digital converters are the main
culprits when it comes to latency.
http://www.ethersound.com/technology/overview.php
Cheers
Pierre-Olivier
On 06/03/2013 12:41, katja wrote:
Netjack docs look promising. It binds Jack clients on the transmitter
computer (called 'slave') to the sample clock on the receiver computer
('master'). Netjack supports transmission over wifi, and over internet
(using the CELT codec). It is primarily designed for 'distributed
music'. Here is a paper introducing Netjack:
http://www.google.nl/url?q=http://lac.linuxaudio.org/2009/cdm/Saturday/22_Hohn/22.pdfsa=Uei=0AM3UajlJIfAO5qDgIgFved=0CDgQFjAJusg=AFQjCNF47yIrp3T6cuIXCKhl0AUIaeiA2w
For anyone using Pd on a mobile device as sound generator, Netjack
could be a great way to deliver audio over wifi. For my purpose
though, I still need access to the sound card at the transmitter side
to capture audio from a mic. An audio rate conversion routine called
AlsaInOut is provided with Netjack so you can use the slave's sound
card for playback. However, this can not be used for capturing or
monitoring, due to large processing delay. So, clock drift is the show
stopper here.
Clock drift is not related to network transmission but to the slight
differences in clock speeds of sound cards even if they are set to the
same nominal sample rate. It also happens with two sound cards used
together on one computer, like when using an USB mic for input and the
system sound card for output. Core Audio can handle such a setup, but
at the expense of increased and fluctuating latency. Jack can combine
soundcards, but buffer under- or overruns are audible.
What is so hard about compensating clock drift? If it must be done in
a theoretically correct way, pitch should not change so it will be a
time stretching routine which will indeed introduce considerable
latency. However, clock speeds often differ by a very small amount,
like a factor 1/1000 or less. What if we just accept the pitch
difference? You would get playback speeds like 1.001 or 0.999,
perfectly acceptable for my purpose at least. This would greatly
simplify the task of resampling.
Katja
On 3/5/13, Charles Goyard c...@fsck.fr wrote:
Re: [PD] How to force OSS MIDI via command line argument
This is probably something I should fix... MIDI used to default to 'OSS' on linux and now defaults to 'alsa' - but I'm not sure that's really the appropriate default. In any event, since it now defaults to alsa we clearly need a 'ossmidi' flag! In the meantime, I put this in my .pdsetting o nthe pi so I can get OSS MIDI by default, and then it's possible again to say -alsamidi to override that to get ALSA if needed. cheers Miller On Fri, Feb 15, 2013 at 10:31:41AM +0100, Antoine Villeret wrote: hi, I need to force the use of OSS MIDI instead of alsa on my RPi. I don't know why, alsa is the default whereas there is nothing saying that in startup flags nor in config file. There is a -alsamidi, but is there an -ossmidi option ? cheers antoine -- do it yourself http://antoine.villeret.free.fr ___ 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
Re: [PD] GPIO - Python (pyata) - PD ?
Alternatively, and perhaps a bit easier, you could grab my gpio object from http://crca.ucsd.edu/~msp/syllabi/206.13w/index.htm - it's very unfinished, but basically you can use the gpio command to set the pins up, then crank up Pd and use a |gpio| object to read or write them - it works through the /sys/class/gpio/ mechanism and is fine for rates up to about 1000 per second (so it's limited by Pd's scheduling resolution). cheers Miller On Thu, Feb 14, 2013 at 05:26:20PM +, João de Brito Rocha Reis Vidigal wrote: Hi guys! Is it too stupid to assume that I can get control of the GPIO via python and send the data to PD via pyata!? All I really need is to read a pushbutton! tks JV ___ 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
Re: [PD] GPIO - Python (pyata) - PD ?
... and oops, I see that the thread got split - on the other thread, the solution from jack at rybn.org (using built-in Pd objects, notably |textfile|) also works, and is certainly the easiest way to get started. cheers Miller On Thu, Feb 14, 2013 at 10:27:02AM -0800, Miller Puckette wrote: Alternatively, and perhaps a bit easier, you could grab my gpio object from http://crca.ucsd.edu/~msp/syllabi/206.13w/index.htm - it's very unfinished, but basically you can use the gpio command to set the pins up, then crank up Pd and use a |gpio| object to read or write them - it works through the /sys/class/gpio/ mechanism and is fine for rates up to about 1000 per second (so it's limited by Pd's scheduling resolution). cheers Miller On Thu, Feb 14, 2013 at 05:26:20PM +, João de Brito Rocha Reis Vidigal wrote: Hi guys! Is it too stupid to assume that I can get control of the GPIO via python and send the data to PD via pyata!? All I really need is to read a pushbutton! tks JV ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
Just a comment on Chris's last point: Also, I don't get the obsession with the Pi. There are now lots and lots of under $100 ARMv7 dual core (!) boards that run Linux and have way more I/O options. Why not get something not totally out of date to begin with? My personal reasons for being attracted to the Pi are, 1, that it's vastly better engineered and supported than other linux+ARM solutions I've seen; and 2, although I'm not sure about this, it seems to dissipate much less power than ARMV7 soutions making it easier to make standalone gadgets with it. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi : DSP on the GPU ? (WAS : Message from the boss of Raspberry Pi Foundation !)
I/O options. Why not get something not totally out of date to begin with? My personal reasons for being attracted to the Pi are, 1, that it's vastly better engineered and supported than other linux+ARM solutions I've seen; and 2, although I'm not sure about this, it seems to dissipate much less power than ARMV7 soutions making it easier to make standalone gadgets with it. So are there low-cost battery packs made to go with it that are plug and go? From what I read it sounds really tricky. -Jonathan I don't know what specifically people are doig, just that there are projects popping up all the time in which people use Pis in autonomous devices that fly or drive around. I'm actually planneng to give this a first try myself tomorrow at Crashspace in LA (http://blog.crashspace.org/ - second posting down) - but I'll be borrowing a battery pack from Joe Deken of New Blankets who's helping instigate the event. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd vanilla 0.44-2 (update to fix denormal behavior for Raspberry Pi)
I'm not involved in the Pd linux distributions for Pi but new versions of Pd seem to trickle down to them after some delay. But if you want the newest, just grab it, un-tar it into your home directory, and in your .bashrc make an alias like alias pd=/home/pi/pd/bin/pd and you'll be able to type pd to new shell windows to get it started - that's how I do it anyhow. cheers Miller On Tue, Feb 05, 2013 at 02:54:52AM -0200, Alexandre Torres Porres wrote: how difficult to just get this version in the raspian repo so we can all just do apt-get? that's a good one since that's as far as my linux expertise goes so far, the RPI is my first linux ;) 2013/2/3 me.grimm megr...@gmail.com what would be the best practice for installing this? of course i could cd /to/pd/bin/ ./pd but better yet just pd from terminal would be swanky and maybe not just run pd from ~/Desktop or ~/ or whatever. how difficult to just get this version in the raspian repo so we can all just do apt-get? m On Fri, Feb 1, 2013 at 1:40 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, This is only of interest to Raspberry Pi users - I've fixed the denormal problem Katja reported and recompiled - you can get that and the new sources from the usual sources: http://crca.ucsd.edu/~msp/software.htm or git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd and pulseaudio (was: ALSA output error (restart failed): Broken pipe)
Just to comment on why I ended up un-installing portaudio: I booted my Pi with a clean new Raspbian distro, compiled Pd (after installing some packages like git and alsa libs), ran it and found that pulseaudio was running. So I exit Pd and likk pulseaudio via pulseaudio -kill. Then start Pd and find it _still_ can't open audio. Why? ell, looking back I found that pulseaudio was running again! So I re-killed it and tried a third time. Same result: for some reason, the mere act of starting Pd was causing pulseaudio to start itself up and grab the audio device so that Pd couldn't get it. There are similar plot sequences in old Three Stooges and Marx Brothers movies, but I wasn't exactly laughing. What if I were about to have to walk on stage with this thing? So I googled around and read through the many-page man page for pulseaudio and found no explanation of why this was happening, nor any suggestions for how to disable pulseaudio other than the -kill command I had already tried. After a while I lost patience and uninstalled pulse and I suggest that everyone else do so as well. cheers Miller Many people who use Pd a lot uninstall pulseaudio entirely. Ok, let's clear some dust here. There seems a strong notion that pulseaudio is interfering a lot with other audio applications and is causing lots of troubles. Let me point out a few facts from a standard Ubuntu 12.04 installation: * When no pulseaudio client is playing, the sound device is not occupied and thus non-compliant applications like Pd are _not_ blocked from accessing the device. This is even the case when you pause a Youtube movie in the browser. * pasuspender is actually not necessary in most cases. Only when some pulseaudio client is actually playing, you may want to use pasuspender. However, using pasuspender does not harm, even if it is not necessary * Use pasuspender -- pd-extended instead of pasuspender pd-extended, so that options passed to pd-extended are bypassed by pasuspender. * Uninstalling pulseaudio is completely unnecessary, as it doesn't solve any problem. OTOH, it also doesn't harm. However, when pulseaudio is installed and Firefox is playing some Youtube movie, you still are able to grant Pd access to the sound device by using pasuspender. With no pulseaudio installed, the flash-plugin might use ALSA directly and there is no other way to stop it from blocking the sound device than to stop firefox. If you don't know which application is currently using the device, good luck with hunting. My point is: With pulseaudio it is actually easier to guarantee Pd access to the sound device. * Jackd (qjackctl, respectively) behaves similar to Pd: When no pulse client is playing, you can just start it without any troubles. Roman ___ 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
Re: [PD] Pd and pulseaudio (was: ALSA output error (restart failed): Broken pipe)
Pulseaudio respawns itself, unless you've configured it not to. You can disable it temporarily with the tool pasuspender. The syntax would be: pasuspender -- pd Good to know - but even though I now theoretically know how to deal with this, the whole thing gives me the creeps - what if some update changes the rules and pulse starts re-spawning itself again? I'll feel safer with it uninstalled - then it will have a much harder time restarting itself on my machine. cheers Miller ___ 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
[PD] [PD-announce] Pd vanilla 0.44-2 (update to fix denormal behavior for Raspberry Pi)
Hi all, This is only of interest to Raspberry Pi users - I've fixed the denormal problem Katja reported and recompiled - you can get that and the new sources from the usual sources: http://crca.ucsd.edu/~msp/software.htm or git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] raspberry pi user experience
I heard suggestions on the Pi sites (I forget exactly where) that the USB 2.0 implementation isn't compatible with a large variety of USB 2.0 devices (including for instance the Griffin iMic). So I don't think the issue is the load that USB 2.0 puts on the Pi, it's simply bugs. But I gather nobody is in a hurry to get them fixed - the attitude in Cambridge is that it's the devices' fault, not the Pi's. I have beem suspecting that my keyboard is also incompatible with the Pi at USB 1.1 speed. I haven't tried other keyboards yet since I'm usually happy to ssh in without any other USB devices (besides audio and ethernet) talking to the Pi. But this is not always true so soon enough I'll have to try other keyboards so I can get the thing working as a standalone computer. cheers Miller On Sun, Jan 27, 2013 at 04:50:16PM +0100, katja wrote: Thanks Pierre and Cyrille. It turned out that various keyboards and mouse just kill USB (when at 1.1) on the Pi. 'Keysonic Wireless Trackball Keyboard' happens to work well. The lower USB speed brings substantial improvement of the audio indeed. Now a real realtime kernel, that would probably improve things further. Katja On Sun, Jan 27, 2013 at 2:33 PM, Cyrille Henry c...@chnry.net wrote: i put it in front of everything : dwc_otg.speed=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait cheers c Le 27/01/2013 11:42, katja a écrit : Hello, Some people seem to have result with setting lower USB speed on the Pi, but when I try this, the Pi doesn't even respond to keyboard anymore. Checking /boot/cmdline.txt with another computer, I'm sure it is not due to a typo. But the order of settings may be important? Could anyone copy the full text of /boot/cmdline.txt for me, if you have keyboard working with lowered USB speed? (I'm not talking about good audio yet). Thanks, Katja On Sat, Jan 26, 2013 at 8:54 PM, Thomas Grill g...@g.org wrote: Message to self: it seems that one has to wait for updated RPi USB firmware/drivers to get USB 2.0 audio going. Obviously the isochronous transfer mode as used by audio interfaces is currently broken. gr~~~ 2013/1/26 Thomas Grill g...@g.org Hi all, for my USB audio class 2.0 device Native Instruments Komplete Audio 6 i can't report such good news. There is constant irregular crackling, not only with Pd but also with aplay etc. It seems related to USB bandwidth, since turning on and off the inputs in Pd changes crackling frequency. The dwc_otg.speed setting is not usable for me, since the device is dependent on USB 2.0 operation. Any experiences with USB 2.0 audio devices under ALSA/rpi? thanks, gr~~~ 2013/1/26 Cyrille Henry c...@chnry.net hello, I just install raspbian release and update it. then install pd 0.44.1 (without any specific optimisation flag) I made the standard optimisation : * - rtprio 99 * - memlock 10 in /etc/security/limits.conf and dwc_otg.speed=1 in /boot/cmdline.txt as suggested by miller I use a uca222 beringher (that cost about 20 or 25€) sound card. trying the test audio and midi, there is no click with 10ms audio buffer (with adc~ enable). this is with usb keyboard / mouse combo plugged and graphical interface (for the system and for pd). without X, audiobuf can be as low as 5ms having a usb keyboard did not change anything for me. i'm very happy cheers c ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Thomas Grill http://g.org -- Thomas Grill http://g.org ___ 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 ___ 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
Re: [PD] remote desktop on the Pi and other questions about it
... and to fill out the other possibility, it's also possible to install the X windows app on Macintosh, get a terminal running inside X, then ssh over to the pi (ssh -X address) - in which case the windows you open on the pi should appear back on the Mac. This might be the lowest-tech way. cheers Miller On Mon, Jan 28, 2013 at 01:16:43AM -0200, Alexandre Torres Porres wrote: nice, that's one of the things that came uo, and apparently there's a nica guide on it: http://4dc5.com/2012/06/12/setting-up-vnc-on-raspberry-pi-for-mac-access/ that should do, right? If the link above is very helpful, we could reference it in the Pd site. This was very helpful too to install it http://lifehacker.com/5976912/a-beginners-guide-to-diying-with-the-raspberry-pi I have the pi, but no way to plug it in with monitors, ethernet, mouse and keyboard yet, tomorrow I'll properly try it out. Now, what about still being able to use the internet on the Pi while connected to the laptop? Can it feed through the same cable, or do I need to have some wi-fi receptor in the USB? How do you do it Mark? Cheers Alex 2013/1/27 me.grimm megr...@gmail.com I'm away from my computer so I could probably tell you more tomorrow. I'm using tightvnc http://elinux.org/RPi_VNC_Server You can set it up so you can use screen sharing on Mac to have your rip desktop on your Mac. That's what I do. It's different than what millers doing with x-forwarding. Also with this you can get the rpi to show up in your finder side bar. Hope that helps! M On Jan 27, 2013, at 7:40 PM, Alexandre Torres Porres por...@gmail.com wrote: Hello Pi people, I just got one of these to mess with, getting it to run the OS was very simple, need help with other stuff. What do you recommend for remote desktopping (controlling the Pi via a laptop, by having the laptop's keyboard/trackpad as input and getting the screen to show what's going on). I know there's something called VNC around, but it seems to come in different softwares, which one(s) have you been using. Or, better put, just about anyone works? I got a macbook air I'd like to use that way, by the way, so I need to run from a MAC OS system. To see if I got this straight, all the hardware you need to plug them together is a crossover ethernet cable, right? That way, can the Pi also feed from the internet I'm getting into my macbook air vi wi-fi while it's being remotely controlled by the same laptop via the same cable? I guess that's it for now. I hope we can have sometime soon a nice page with several info on how to run Pd in the Pi in many ways. I could help on writting this kind of tutorial Cheers ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gpio on the raspberry pi from within pd ?
Since writnig that I think I found a good toolset and C api, called WiringPi, on: https://projects.drogon.net/raspberry-pi/wiringpi/ cheers Miller On Sat, Jan 26, 2013 at 10:29:17AM +0100, Charles Goyard wrote: Hi, python rpi-gpio uses /dev/mem and thus requires root privileges. Miller Puckette wrote: Me, I was just planning to see how the python-GPIO library does it and make similar Pd externs. But I don't know what I'm doing :) ___ 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
Re: [PD] gpio on the raspberry pi from within pd ?
Me, I was just planning to see how the python-GPIO library does it and make similar Pd externs. But I don't know what I'm doing :) M On Fri, Jan 25, 2013 at 10:12:49AM +0100, Antoine Villeret wrote: hi all, i made a small program which uses GPIO to scan a keypad matrix and send OSC data to pd it depends on liblo and libbcm2835 it's very specific to my project but could help someone... code is here : https://github.com/avilleret/pianophone cheers a -- do it yourself http://antoine.villeret.free.fr 2013/1/25 Charles Goyard c...@fsck.fr Hi Miller, Miller Puckette wrote: I think either I or a grad student (we'll see) will be writing a Pd extern to do this efficiently -- for the moment it would be possible with a Python script (using netsend/netreceive in Pd) but having an extern would be more lightweight and probably more robust. great, thanks! Meanwhile I found out about webiopi, which can act as a placeholder ATM. (http://code.google.com/p/webiopi/wiki/RESTAPI) Will you use /dev/mem and require root privileges, or the /sys/class/gpio filesystem? (see http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29t=9667p=198848 for how to change permissions, non-standard !) -- Charlot ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd vanilla 0.44-1 ASIO
Well, the only thing I think the two could share in common is their entry in the Windows registry - can you try deleting all the Pd entries? The keys are under HKEY_LOCAL_MACHINE\Software\Pd - you can zap them using regedit. Then crank up the older Pd and see if that fixes it... cheers Miller On Thu, Jan 24, 2013 at 08:57:05AM -0800, Hrvoje Radnic wrote: now it seems even worse... now I can't use 0.43-3 anymore. Is it because I tried to run 0.44-0 for a moment? Just to mention, I have run it from completely different location i.e. separate disk. As far as I remember, all 0.43-x versions worked nice on my (winxp + rme hammerfall) system. Things went wrong somehow when I started to use 0.44-x. Thanks for your help! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 2:20 AM Subject: Re: [PD] pd vanilla 0.44-1 ASIO ... and does pd-0.44-0 (or pd-0.43-2) still work? I'd be surprised if the change from 0.44-0 to 0.44-1 broke that but who knows. I happen to have a Hammerfall and a working PC so once I get them in the same building I can try this too. thanks Miller On Wed, Jan 23, 2013 at 03:03:41PM -0800, Hrvoje Radnic wrote: Hi there! Recently, I've upgraded from pd vanilla 0.43-3 to 0.44-1 and since then I can't choose ASIO Hammerfall DSP as an audio in/out. I found this interesting announcement from M. Puckette which says: Hi all - Time for the first Pd 0.44 bug fix. I changed the choice of default API (so that MMIO is preferred to ASIO on windows; ALSA before jack on linux, and core audio before jack on Mac OSX - this is so that first-time Pd users who haven't yet chosen an API are reasonably likely to get audio on the first try. cheers Miller Does anyone knows what I need to do to fix the problem? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd launched via rc.local can't search path
This is mysterious to me - but it might help to put copies of all needed abstractions in the directory that holds the patch you're asking Pd to load. There mihgt be some chroot magic going on ni teh boot sequence that's changing the meaning of paths somehow - that's a wild guess but at least if it's something like that you can work around it. cheers Miller On Thu, Jan 24, 2013 at 08:52:49PM +0100, Pierre Massat wrote: Hi, all of my paths are absolute. There are in /usr/bin/puredata. Do you think it could be that /usr/ isn't mounted yet when Pd is launched by rc.local? 2013/1/24 padawa...@obiwannabe.co.uk padawa...@obiwannabe.co.uk ** On 24 January 2013 at 18:35 Pierre Massat pimas...@gmail.com wrote: Hi, I'm trying to get Pd to run at startup. I've put the command in /etc/rc.local. Everything works fine, except that Pd seems to be unable to search the paths I specified (either in .pdsettings or directly in the command line). I'm trying to use a patch with the reverb described in the audio examples (G.08 I think), and there's an abstraction in it which lives in 3.audio.examples. Every time I boot Pd starts all right, but I get errors because it can't create the abstraction. It's a bit weird because the very same command works like a charm once i've logged in. Make sure all paths are absolute, and not relative to a tilde (user home) and point to world readable directories. Starting via rc.local will mean the application is launched as root, and since there is no login shell and cwd associated at the time it is launched the paths you specify when logged in probably make no sense. ___ 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
Re: [PD] pd vanilla 0.44-1 ASIO
Very brief release notes are in http://crca.ucsd.edu/~msp/Pd_documentation/x5.htm#s1 of for al lteh gory details you can look at the git log on: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=log ... Would it be possible for you to run 0.44-1 again, save settings (so that your registry breaks again) - verify that it's broken still for 0.43, then somehow copy all the Pd registry settings so I can see them? Even better would be if you could show me the Pd registry settings before and after saving them from 0.44 so I can try to guess what setting it is that's causing the trouble. thanks Miller On Thu, Jan 24, 2013 at 12:27:18PM -0800, Hrvoje Radnic wrote: Yes, it is working again...(0.43-3) I tried 0.44-0 with the same procedure, but without success. I have one more related question, is there a way to find out which are the changes in every new pd vanilla release? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 8:44 PM Subject: Re: [PD] pd vanilla 0.44-1 ASIO Well, the only thing I think the two could share in common is their entry in the Windows registry - can you try deleting all the Pd entries? The keys are under HKEY_LOCAL_MACHINE\Software\Pd - you can zap them using regedit. Then crank up the older Pd and see if that fixes it... cheers Miller On Thu, Jan 24, 2013 at 08:57:05AM -0800, Hrvoje Radnic wrote: now it seems even worse... now I can't use 0.43-3 anymore. Is it because I tried to run 0.44-0 for a moment? Just to mention, I have run it from completely different location i.e. separate disk. As far as I remember, all 0.43-x versions worked nice on my (winxp + rme hammerfall) system. Things went wrong somehow when I started to use 0.44-x. Thanks for your help! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 2:20 AM Subject: Re: [PD] pd vanilla 0.44-1 ASIO ... and does pd-0.44-0 (or pd-0.43-2) still work? I'd be surprised if the change from 0.44-0 to 0.44-1 broke that but who knows. I happen to have a Hammerfall and a working PC so once I get them in the same building I can try this too. thanks Miller On Wed, Jan 23, 2013 at 03:03:41PM -0800, Hrvoje Radnic wrote: Hi there! Recently, I've upgraded from pd vanilla 0.43-3 to 0.44-1 and since then I can't choose ASIO Hammerfall DSP as an audio in/out. I found this interesting announcement from M. Puckette which says: Hi all - Time for the first Pd 0.44 bug fix. I changed the choice of default API (so that MMIO is preferred to ASIO on windows; ALSA before jack on linux, and core audio before jack on Mac OSX - this is so that first-time Pd users who haven't yet chosen an API are reasonably likely to get audio on the first try. cheers Miller Does anyone knows what I need to do to fix the problem? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd vanilla 0.44-1 ASIO
INteresting... the two files are identical unless I'm missing something. (but still, deleting the registry entries fixes Pd 0.43 --- what on earth can this mean...) thanks M On Thu, Jan 24, 2013 at 12:50:53PM -0800, Hrvoje Radnic wrote: Sure, .reg files are in the attachment. Cheers Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 9:37 PM Subject: Re: [PD] pd vanilla 0.44-1 ASIO Very brief release notes are in http://crca.ucsd.edu/~msp/Pd_documentation/x5.htm#s1 of for al lteh gory details you can look at the git log on: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=log ... Would it be possible for you to run 0.44-1 again, save settings (so that your registry breaks again) - verify that it's broken still for 0.43, then somehow copy all the Pd registry settings so I can see them? Even better would be if you could show me the Pd registry settings before and after saving them from 0.44 so I can try to guess what setting it is that's causing the trouble. thanks Miller On Thu, Jan 24, 2013 at 12:27:18PM -0800, Hrvoje Radnic wrote: Yes, it is working again...(0.43-3) I tried 0.44-0 with the same procedure, but without success. I have one more related question, is there a way to find out which are the changes in every new pd vanilla release? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 8:44 PM Subject: Re: [PD] pd vanilla 0.44-1 ASIO Well, the only thing I think the two could share in common is their entry in the Windows registry - can you try deleting all the Pd entries? The keys are under HKEY_LOCAL_MACHINE\Software\Pd - you can zap them using regedit. Then crank up the older Pd and see if that fixes it... cheers Miller On Thu, Jan 24, 2013 at 08:57:05AM -0800, Hrvoje Radnic wrote: now it seems even worse... now I can't use 0.43-3 anymore. Is it because I tried to run 0.44-0 for a moment? Just to mention, I have run it from completely different location i.e. separate disk. As far as I remember, all 0.43-x versions worked nice on my (winxp + rme hammerfall) system. Things went wrong somehow when I started to use 0.44-x. Thanks for your help! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova From: Miller Puckette m...@ucsd.edu To: Hrvoje Radnic hrvojerad...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Thursday, January 24, 2013 2:20 AM Subject: Re: [PD] pd vanilla 0.44-1 ASIO ... and does pd-0.44-0 (or pd-0.43-2) still work? I'd be surprised if the change from 0.44-0 to 0.44-1 broke that but who knows. I happen to have a Hammerfall and a working PC so once I get them in the same building I can try this too. thanks Miller On Wed, Jan 23, 2013 at 03:03:41PM -0800, Hrvoje Radnic wrote: Hi there! Recently, I've upgraded from pd vanilla 0.43-3 to 0.44-1 and since then I can't choose ASIO Hammerfall DSP as an audio in/out. I found this interesting announcement from M. Puckette which says: Hi all - Time for the first Pd 0.44 bug fix. I changed the choice of default API (so that MMIO is preferred to ASIO on windows; ALSA before jack on linux, and core audio before jack on Mac OSX - this is so that first-time Pd users who haven't yet chosen an API are reasonably likely to get audio on the first try. cheers Miller Does anyone knows what I need to do to fix the problem? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gpio on the raspberry pi from within pd ?
Hi Charlot - I think either I or a grad student (we'll see) will be writing a Pd extern to do this efficiently -- for the moment it would be possible with a Python script (using netsend/netreceive in Pd) but having an extern would be more lightweight and probably more robust. I'm running an informal seminar about Pi stuff and once we get it together we're planning to blog what we end up doing. cheers Miller On Thu, Jan 24, 2013 at 06:09:03PM +0100, Charles Goyard wrote: Hi list, is there some external or stdout/daemon trick to access the gpio from pd on the Raspberry pi ? Thanks -- Charlot ___ 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
Re: [PD] Pd-extended 0.43.4 final builds
That's an old, annoying bug in Vanilla... cheers Miller On Thu, Jan 24, 2013 at 11:29:07PM -0500, Hans-Christoph Steiner wrote: On 01/24/2013 10:38 PM, Seiichiro MATSUMURA wrote: Hi Hans, It's great to hear this! Through checking this final builds, I notice 2 weird behaviors of it working on Mac OS10.8. 1. When making Array first time, pop up Array properties always tells its Draw as way is Polygon. However, when I open Array properties after Array made, it tells Points and it is actually Points. Is this a bug? Hmm, yes, that sounds like a bug, but I won't be able to fix it in this release. Could you file a bug report? 2. In Media - Audio Settings..., a tail of the device name of Built-in Microphone is cut like Built-in Microph. (see attached jpeg) I am not sure whether this originally happens in Japanese OS. I can't change the name of Built-in Microphone in Mac OS10.8 So does anyone who uses English Mac OS see this no problem? This has been reported before, it seems to affect all Mac OS X 10.8. I have no idea what's causing it, and it doesn't seem to affect the operation. Please add any details you can think of here: https://sourceforge.net/tracker/index.php?func=detailaid=3575978group_id=55736atid=478070 .hc I think these are not major problems, but I would like to know solutions if possible. Best, Sei -- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura s...@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ 2013/1/25 Hans-Christoph Steiner h...@at.or.at: I've started posting the final builds for Pd-extended 0.43.4. Here are the Windows and Mac OS X builds: https://sourceforge.net/projects/pure-data/files/pd-extended/0.43.4/ These are the Ubuntu builds, there will be one small change in the final builds: the version will be changed to 0.43.4 from 0.43.4~extended2: https://launchpad.net/~eighthave/+archive/pd-extended/+packages same as Ubuntu but for Debian: http://autobuild.puredata.info/auto-build/2013-01-24/ And the source tarball, which also just needs the version change: http://autobuild.puredata.info/auto-build/2013-01-24/Pd-extended_0.43.4~extended-source.tar.bz2 The version change will be in tomorrow's builds. .hc ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi - Audio in and out, low latency
audiodev and other device selecting options (MIDI for example) count the devicesstarting at 1 (probably because the first OS I ran Pd on did it that way but I don't even remember now). invoke pd -listdev' to see what devices Pd actually thinks it can access and how it numbers them. cheers Miller On Wed, Jan 23, 2013 at 10:56:55AM +0100, Pierre Massat wrote: Hi, thank you for your replies. Of course I know man, but honestly i didn't bother to read it... I did try '-audiodev 1' (my card shows up as card 1), but it didn't work. I'll try again tonight. Cheers, Pierre. 2013/1/23 IOhannes m zmoelnig zmoel...@iem.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-23 09:49, Pierre Massat wrote: Unless there's a better place on the web to learn about start-up flags, i think it would be a good idea to provide more details on the community website. I always find it frustrating when i have to spend a lot of time figuring out how to use a command line program just because i don't know the syntax of the arguments. on unix systems, about each and every cmdline tool has a manpage. $ man pd most programs i know, also accept a -h or --help argument, that gives you another help. Pd is a bit exclusive here, as it uses the -help syntax (but then Pd is clever enough to give you the full help whenever it encounters an argument it doesn't know about; so pd -h and pd --help work fine as well). $ pd -help in the case of Pd, the manpage is a little neglected, but at least it directs you to pd -help. fgamsd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD/rkQACgkQkX2Xpv6ydvTONgCgnt2RHZ3UVlLIY8tndFgQoqIq oxcAoJ5wTDLC9GoRiJhUl2FJTfA0iIKg =ries -END PGP SIGNATURE- ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd vanilla 0.44-1 ASIO
... and does pd-0.44-0 (or pd-0.43-2) still work? I'd be surprised if the change from 0.44-0 to 0.44-1 broke that but who knows. I happen to have a Hammerfall and a working PC so once I get them in the same building I can try this too. thanks Miller On Wed, Jan 23, 2013 at 03:03:41PM -0800, Hrvoje Radnic wrote: Hi there! Recently, I've upgraded from pd vanilla 0.43-3 to 0.44-1 and since then I can't choose ASIO Hammerfall DSP as an audio in/out. I found this interesting announcement from M. Puckette which says: Hi all - Time for the first Pd 0.44 bug fix. I changed the choice of default API (so that MMIO is preferred to ASIO on windows; ALSA before jack on linux, and core audio before jack on Mac OSX - this is so that first-time Pd users who haven't yet chosen an API are reasonably likely to get audio on the first try. cheers Miller Does anyone knows what I need to do to fix the problem? Thank you! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova ___ 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
Re: [PD] Pd Vanilla download stats
Hi all, I went looking in the logs and over a recent 28-day period I found only 441 distinct addresses downloading recent (0.43 or 0.44) versions of Pd - so between 15 and 16 'unique' downloads per day. (The total number was over 6000 but I think unique addresses is a better measure.) cheers Miller On Tue, Jan 22, 2013 at 02:35:51PM +, Jamie Bullock wrote: Hi, Does anyone have download stats (monthly / yearly) for Pd Vanilla? I know there are some on Sourceforge, but that's not the complete picture — how about the downloads from Miller's site? Thanks, Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
thanks - I'd better try this and find out what's going on :) M On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: Tried the 0.44.0 build from your website. It has the same issue with subnormal values. My test patch is with [lop~]. If inf or nan is fed into [lop~], these 'values' keep circulating in the object, it can no longer process normal signal values. I also tried my reverb stuff with specific compiler options for Pi's processor: -march=armv6zk -mcpu=arm1176jzf-s -mtune=arm1176jzf-s With these options, gcc should be able to decide that RunFast mode is permitted. But even in combination with -ffast-math (which in turn sets -funsafe-math-optimizations and -fno-trapping-math amongst others), denormals are still there. I'm literally out of options for the moment. Sorry for not having better news. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi - Audio in and out, low latency
That's great (and surprising) news... I wonder why you're getting a better ride from teh E-MU box than I am from the iMic but it sounds as if I should be digging up one like yours to try. I think you can just invoke 'pd -sounddev 2' to select the USB device. cheers Miller On Tue, Jan 22, 2013 at 09:23:51PM +0100, Pierre Massat wrote: Dear list, dear Miller, I tried Pd on a fresh Raspbian install today. I removed pulseaudio as you suggested. I installed Pd from the Raspbian repos (not your version). I tried it with my USB E-MU 0404 soundcard. It worked right away. No need to slow down the USB. I tried with a latency in Pd of 10 ms, in X, connected to the internet, and there was very little dropouts. This is so promising it's scary. Now i have one very frustrating problem : i don't know how to choose my soundcard from the command line when starting Pd... It shows up as Card 1, device 0 when i do aplay -l, but i don't know how to use this information. Cheers! Pierre. ___ 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
Re: [PD] Raspberry Pi does denormals
Hi all... I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by calling gcc with --fast-math. At any rate what I found was that, if I compiled without --fast-math, when numbers got small (e.g., when a reverberator decays down past 10^-38 or so), the patch would suddenly jump in CPI usage as if it were trappnig to the kernel (as it does for i386). But when I added --fast-math the problem went away. On i386 and x86_64, I believe that one can't get flush-to-zero (at least in the normal non-SSE floating point instructions) so there's no choice but to use a macro such as PD_BADFLOAT to protect against that. So in m_pd.h the PD_BADFLOAT macro is only turned on for Intel. However I've been mistaken many times about all this in the past and won't be surprised if I'm mistaken again. cheers Miller On Sun, Jan 20, 2013 at 11:12:28AM -0500, Hans-Christoph Steiner wrote: I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little processor? There seems to be something called 'RunFast mode' for Pi's float processor vfpv2, but I see no way how to enable this via gcc. Option -ffast-math is allowed but doesn't do the trick. Can't find an option to set vfpv2 specifically, in gcc docs. Katja ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
OK.. but try the 0.44 build on my site - the one from Raspian is quite old :) M On Sun, Jan 20, 2013 at 09:28:30PM +0100, katja wrote: Miller, the vanilla Pd which can be installed from Raspbian with apt-get or Synaptic does have the subnormals problem, as can be checked with a test patch attached with my first post. When an input signal to [lop~] is shut off, CPU load increases substantially. Output values go down in the order of 1e-44, subnormal range. I was working on reverb algo's showing the same problem, and compiled with option -ffastmath / --fast-math to see if that would turn on RunFast mode, but it didn't. I'm not familiar with ARM and it's coprocessors, but from Intel I do know that gcc doesn't implement certain specified optimization options (notably SSE versions) unless you also mention a processor type that can handle it . A similar case could be with Rpi's vfpv2; it can do RunFast mode but gcc doesn't implement it, until you find a way to specify vfpv2 (vfpv1 can't do RunFast). Miller, if you succeeded in getting automatic flush-to-zero on the Pi, it may be related to other flags which you've set. Arch flags which I've set so far are -march=armv6 and -mfpu=vfp. Option -mfpu=vfpv2 is not allowed. I would be happy to do further testing with compiler options, if you know some. The big-or-small checks are rather expensive for RPi, that's what I've found. Katja On Sun, Jan 20, 2013 at 8:24 PM, Miller Puckette m...@ucsd.edu wrote: Hi all... I think it's possible to get flush-to-zero behavior on the Pi (ARMv6) by calling gcc with --fast-math. At any rate what I found was that, if I compiled without --fast-math, when numbers got small (e.g., when a reverberator decays down past 10^-38 or so), the patch would suddenly jump in CPI usage as if it were trappnig to the kernel (as it does for i386). But when I added --fast-math the problem went away. On i386 and x86_64, I believe that one can't get flush-to-zero (at least in the normal non-SSE floating point instructions) so there's no choice but to use a macro such as PD_BADFLOAT to protect against that. So in m_pd.h the PD_BADFLOAT macro is only turned on for Intel. However I've been mistaken many times about all this in the past and won't be surprised if I'm mistaken again. cheers Miller On Sun, Jan 20, 2013 at 11:12:28AM -0500, Hans-Christoph Steiner wrote: I think this is what you want, from 'man gcc'. Its interesting to note that the NEON mode, which provides SIMD, also does not do denormals: -mfpu=name -mfpe=number -mfp=number This specifies what floating point hardware (or hardware emulation) is available on the target. Permissible names are: fpa, fpe2, fpe3, maverick, vfp, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16 and neon-vfpv4. -mfp and -mfpe are synonyms for -mfpu=fpenumber, for compatibility with older versions of GCC. If -msoft-float is specified this specifies the format of floating point values. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations will not be used by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. .hc On 01/20/2013 06:54 AM, katja wrote: I was assuming, or maybe just hoping? that Raspberry Pi (and ARM devices in general) would not suffer from Denormal's disease like Intel processors do. But guess what: Pi's float coprocessor is IEEE 754 compliant and does all denormals by default (can check with attached denorm-test.pd). Bummer! As if one would use an ARM device to calculate the size of a Majorana particle, rather than doing simple dsp. Do we really need to enable PD-BIGORSMALL() checks for this poor little processor? There seems to be something called 'RunFast mode' for Pi's float processor vfpv2, but I see no way how to enable this via gcc. Option -ffast-math is allowed but doesn't do the trick. Can't find an option to set vfpv2 specifically, in gcc docs. Katja ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info
Re: [PD] Audio output on Raspberry Pi - Recommendations?
Hi all - I just now tried again (after some months of not fooling with it) and got audio in+out working with no trouble at all... from a clean and recently updated Raspian install (i.e. 'apt-get update; apt-get upgrade) I just deleted pulseaudio: apt-get remove pulseaudio and then slowed my USB down to 1.1 speed by adding the setting: dwc_otg.speed=1 to the file /boot/cmdline.txt plugged in a Griggin iMic (bout $25 I think) and immediately got full-duplex audio. I'm running only one channel in and tried it with an electric guitar with the iMic switched to 'mic in' and all worked. I was able to get audio latency down to 10, didn't try any lower than that. This is all without any mouse, keyboard or video monitors connected to the pi - I'mm SSH-ing in. Last time I got up to this point, things started to degrade when I put other USB devices on so I'll try that now... cheers Miller On Fri, Jan 18, 2013 at 01:27:46PM +0100, Cyrille Henry wrote: hello, could you tell a bit more about the alsa tweak? thanks Cyrille Le 18/01/2013 12:06, padawa...@obiwannabe.co.uk a écrit : Yes, I got it goiing for a recent workshop in Nantes ALSA tweaked a bit with the .asoundrc file Hardware: Turtle Beach dongle (Old Amigo 1 I think) Latency: 150ms (total suckage) On 18 January 2013 at 10:49 Julian Brooks jbee...@gmail.com wrote: Apologies for dragging this up again... Can anyone confirm that they have got duplex audio working - in any form with any combination of hdmi, usb or the regular audio out of the rpi, and with which OS, version, tweaks? Still not convinced it's properly doable from our (iMic USB based) experiments. Regards, Julian On 5 January 2013 17:54, Dirk Myers di...@wildvine.com mailto:di...@wildvine.com wrote: Thanks, all. I'll check out the iMic UCA222. Cheers! -- Dirk On Jan 4, 2013, at 12:47 PM, Julian Brooks wrote: +1 on the imic. On 4 January 2013 18:18, Cyrille Henry c...@chnry.net mailto:c...@chnry.net wrote: in fact, both edirol UA1X and beringer uca222 works. they look so similar that I mix there name. sorry Cyrille Le 04/01/2013 18:55, Pedro Lopes a écrit : edirol? Isn't uca222 a behringer card? On Fri, Jan 4, 2013 at 6:48 PM, Cyrille Henry c...@chnry.net mailto:c...@chnry.net mailto: c...@chnry.net mailto:c...@chnry.net wrote: edirol uca222 works great. cheers c Le 04/01/2013 17:49, Miller Puckette a écrit : The best ide I got was from the Griffin iMic (thanks to Joe Deken over at New Blankets for running out and buying a bunch of cheap USB 'adapters' - the Griffin is $40 list / $27 street). The thing looks like an apple product but (as I discovered today looking at it) isn't. Good job of apple-style-imitation-without- __infringing-trademark. The other USB 'adapters' also worked but beware - some take more power than the Pi can supply and some are physically so bulky you can't get anything in the other USB slot - in either case you have to get a powered USB hub and live with a layer of additional uncertainty. cheers Miller On Fri, Jan 04, 2013 at 08:18:00AM -0800, Dirk Myers wrote: Folks: I've been digging through the list searching, haven't found a clear answer: what are folks using for audio output from the Raspberry Pi to a mixing board? I'm leaning toward trying a few USB audio interfaces. Curious about what others have used that is working well. Thanks, Dirk __ ___ Pd-list@iem.at mailto:Pd-list@iem.at mailto: Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list __ ___ Pd-list@iem.at mailto:Pd-list@iem.at mailto: Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/__listinfo/pd-list http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list __ ___ Pd-list@iem.at mailto:Pd-list@iem.at mailto
Re: [PD] canvas properties dialog enhancement ?
That's a good idea... I'll stick it on my list (but I've got years of backlog so it won't happen fast I'm afraid). cheers Miller On Tue, Jan 15, 2013 at 05:15:55PM +0100, Fero Kiraly wrote: hallo, It is possibile for pd developers to make this thing ? : When I have an abstraction object which uses arguments and when the checkbox 'Hide object name args' is checked I am unable to change the arguments. But, if the arguments could be displayed in the canvas properties dialog (mouse right click on the abstraction) somewhere on a new line and editable, it will be a nice feature, I think fero ___ 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
[PD] [PD-announce] pd 0.44-1 released
Hi all - Time for the first Pd 0.44 bug fix. I changed the choice of default API (so that MMIO is preferred to ASIO on windows; ALSA before jack on linux, and core audio before jack on Mac OSX - this is so that first-time Pd users who haven't yet chosen an API are reasonably likely to get audio on the first try. cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to iterate over left and right channel separately in one Pd class?
Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ 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
Re: [PD] how to iterate over left and right channel separately in one Pd class?
copy_perform assumes the data is 4-byte aligned so might save a test or two compared to memcopy() - but I really don't know. I never benchmarked the two against each other :) M On Fri, Jan 11, 2013 at 09:36:41PM +0100, katja wrote: Hi Miller, Thanks for the solution. The routines are in place so copying the right channel input to output should do it. Is there any reason to prefer copy_perform() over memcpy()? I'm trying to make the most efficient reverb for RPi Co. Katja On Fri, Jan 11, 2013 at 7:57 PM, Miller Puckette m...@ucsd.edu wrote: Hi Katja - There's one example of this in sigfft_dspx() - a complex FFT that 'natively' works on 2 signals in-place but has to deal with various cases in which buffers get re-used. It's ugly but the basic idea is first to get the inputs copied to the outputs (unless they're already there in the correct order in which case nothing needs to be done) and then run the in-place algorithm. If the algo only works out-of-place (i.e. you need 4 distinct buffers, 2 in and 2 out) the only way out is (at least conditionally) allocate temporary copies of the inputs before writing to any outputs. I may be able to add an optional way tilde objects can request that output buffers be distinct from input ones sometime in the future - but this is a couple of steps away for me right now :) M On Fri, Jan 11, 2013 at 03:32:09PM +0100, katja wrote: Hello, I'm working on a Pd class with stereo channels (reverb), and the routine happens to be most efficient when iterating over the samples per channel, instead of left and right together in the perform loop. However, when doing two while loops in one object, one for left and one for right, the right channel samples get overwritten because of sample-wise in-place computation. Is this an inescapable truth? I mean, I could write a left channel class and a right channel class (actually did that to verify that it works), but it's inconvenient to use. What could be an efficient way to get them in one object? Thanks, Katja ___ 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Multiple sessions on Windows
Cool... I'm guessing it's now stable enough to call it the official 0.44... I'll get to work on that in a few hours. cheers Miller On Sun, Jan 06, 2013 at 06:26:29PM +0100, Pierre-Olivier Boulant wrote: On 06/01/2013 17:02, Hans-Christoph Steiner wrote: On Jan 6, 2013, at 10:21 AM, Pierre-Olivier Boulant wrote: On 05/01/2013 18:43, Hans-Christoph Steiner wrote: On Jan 5, 2013, at 3:50 AM, Pierre-Olivier Boulant wrote: [... ] .hc Looks like it's back to the old behaviour. If I double click a file it starts a new Pd session. Not that it bother's me really. I mean with the drag and drop plug-in is a nice alternative to double clicking. At least now I can start a second session. pob (sorry for the double post hc) Hmm, I can't reproduce that on my WinXP box. My guess is that you have a custom file association setup in the registry that uses shell\open\command rather than shell\open\ddeexec. And probably, you didn't check Reset File Associations in the installer. Check HKEY_CLASSES_ROOT\.pd to see the association. .hc Thanks, seems ok now. I had over written the whole folder with the zip file. I guess this is the reason why it didn't work. Now I have the ability to open from the launch icon several sessions and the patches open in the first session. As always, thank you very much for looking into this. Cheers Pierre-Olivier ___ 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
