[PD] pduino download?
Hi Hans, Is this still the right link for downloading Pduino? http://at.or.at/hans/pd/Pduino-0.5.zip It's currently timing out (found on this page: http://puredata.info/downloads/pduino/releases/0.5). thanks, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
On 01/19/2013 08:20 PM, Hans-Christoph Steiner wrote: It can be done incrementally, which is likely the only way its going to get done. It turns out that FUDI and tcl proc calls are very similar: space separated list of elements where the first one is the functionality. If the basics were done first, like object drawing, then someone could build a rough GUI with another toolkit to test out. oh yes definitely. i'm personally not interested in building a JUCE-based toolkit for now (and as a matter of fact, am quite happy with the current interface). all my ambitions are directed into abstracting the tcl part away, so that someone _can_ implement an alternative GUI. fgamsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
On 01/20/2013 05:21 AM, Ivica Ico Bukvic wrote: [...] pd-l2ork provides a solid, bug-free environment [...] wow! mfgadrt IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
I was intrigued by this [$@ bug (mainly because i didn't knew about this $@ thingy), so i decided to give it a try. Attached is my test patch. It crashes on my ubuntu 12.10 64bits, Pd-l2ork version 20130111 compiled 13:18:07 Jan 11 2013, way before reaching 1000 args. I launch it in my terminal with : ~$ pd-l2ork test-dollar-at.pd All i have to do is continuously move my mouse over the patch while it's running, and it will crash around 100 args. You can also try to play with the vslider, it will crash. OR (curiously), it won't crash when moving the mouse, but going in and out of edit mode or saving will make it crash... On a side note, look at the patch cord going out of the vslider : it looks weird to me, like attached a few pixels under the vslider, not directly connected to it. Ok now, the fun part : When i open this patch with pd-extended (Pd-0.43.4 (extended-20130118) compiled 09:30:52 Jan 18 2013), [list] only has one inlet (it should have 2, given that it's supposed to behave like [list append]) and when i want to see [list]'s help file, pd-ext opens bang's help file... When i open the same patch with pd-l2ork, the lists do have 2 inlets. Oh, and pd-extended happened to display lists with their 2 inlets, but i can't reproduce this reliably. I tried to open the patch with -noprefs (to ensure that i didn't have a forgotten [list] abstraction somewhere) same issue. Am i cursed or something ? On 20/01/2013 07:35, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Jonathan Wilkes' jancs...@yahoo.com; 'Hans-Christoph Steiner' h...@at.or.at Cc: pd-list@iem.at Sent: Saturday, January 19, 2013 11:21 PM Subject: RE: [PD] enhance pd-extended with pd-l2ork featues ? Why not simply use pd-l2ork? I do, but possible reasons why someone might not use Pd-l2ork: * no binary for windows * no binary for OSX On the flip-side pd-l2ork provides a solid, bug-free environment on Linux and looks a lot more contemporary than the aged default tk iteration. In other words, it is a targeted Linux distribution of pd (something that can be easily lost in a cross-platform effort with inadequate developer support, as I am sure Hans can attest to). At this point I would go as far as challenge you to find something that does not work or exhibits a buggy behavior $@ in msg box probably still crashes when incoming args 1000 (same with pd-extended) -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 80 229 450 300 10; #X obj 116 29 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 116 49 metro 100; #X msg 116 69 1; #X obj 116 90 +; #X obj 140 90 f; #X obj 225 52 nbx 5 55 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 44 -262144 -1 -1 67 256 0; #X obj 189 119 list; #X msg 116 141 \$@; #X obj 225 122 print; #X obj 116 5 loadbang; #X obj 49 -16 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X obj 116 176 print; #X obj 116 119 list; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 5 0; #X connect 3 0 12 0; #X connect 4 0 3 1; #X connect 5 0 8 0; #X connect 6 0 12 1; #X connect 9 0 0 0; #X connect 10 0 12 0; #X connect 12 0 6 0; #X connect 12 0 7 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Jack support on Windows
Really Patrice... But How can I select the text?? I'm trying with the mouse but that's don't working here... 2013/1/19 Patrice Colet colet.patr...@free.fr Excuse the (... lot of letters..) but my cmd don't have ctrl+c option.. :/ hello, Are you really using cmd for compiling, or msys console? On cmd you can select and copy with menu actions, cygwin uses cmd... In msys console it's truly like a unix terminal, Ctrl+Insert and Shift+Insert for copying and pasting ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Esteban Viveros (27) 8815 7170 (27) 3066 0359 (11) 95761 4125 (11) 2738 7868 www.bandpage.com/estebanviveros http://soundcloud.com/estebanviveros https://www.facebook.com/estebanviveros.art http://www.papodecompositor-es.blogspot.com.br/ http://expurgacao.art.br/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Jack support on Windows
HC, can the compilation process gender a log file? 2013/1/18 Hans-Christoph Steiner h...@at.or.at Please Reply All so that your emails go to the list also. Can you post the whole build log? those lot of letters hold the key to the problem :) .hc On 01/18/2013 11:54 AM, Esteban Viveros wrote: Now I can see some letters on cmd... hehehehe But not yet.. I have Error 1 The compilation start with makefile.mingw:300: makefile.dependencies: No such file or directory (... lot of letters ...) makefile.mingw:273: recipe for targets 'makefile.dependencies' failed make: *** [makefile.dependencies] Error 1 Excuse the (... lot of letters..) but my cmd don't have ctrl+c option.. :/ 2013/1/18 Hans-Christoph Steiner h...@at.or.at Oops sorry, it should be: cd ~/pure-data/pd/src make -f makefile.mingw Basically run the make command in the same folder as the file makefile.mingw. .hc On 01/18/2013 09:34 AM, Esteban Viveros wrote: :/ I have the same output.. remembering in ~/pure-data I have now 3 folders: Pd-0.43.4-extended-20130117 pd sources 2013/1/18 Hans-Christoph Steiner h...@at.or.at Oops, yeah, I forgot there is one ugly little detail. Run this in the Terminal: cd ~/pure-data mv pd-extended pd cd pd make -f makefile.mingw Now you can do the rest of the stuff from the previous email. .hc On 01/18/2013 08:10 AM, Esteban Viveros wrote: when I ran the command: make -f makefile.mingw I have the response: (in ~/puredata) make: makefile.mingw: No such file or directory make: *** No rule to make target 'makefile.mingw'. Stop. (in ~/puredata/pd-extended) make: makefile.mingw: No such file or directory make: *** No rule to make target 'makefile.mingw'. Stop. (in ~/puredata/pd-extended/src) makefile.mingw:300: makefile.dependencies: No such file or directory make: *** No rule to make target '../../pd/portaudio/src/common/pa_stream.c' , needed by 'makefile.dependencies'. Stop. 2013/1/17 Hans-Christoph Steiner h...@at.or.at You don't want the auto-build script for this. Its more trouble than its worth. Do this instead: * download the zip version: http://autobuild.puredata.info/auto-build/2013-01-17/Pd-0.43.4-extended-20130117-windowsxp-i386.zip * unzip it into ~/pure-data * run these commands: cd ~/pure-data git clone git:// pure-data.git.sourceforge.net/gitroot/pure-data/pd-extended.git cd ~/pure-data/pd-extended * now copy attached file into ~/pure-data/pd-extended/src/ * now run these commands: make -f makefile.mingw make -f makefile.mingw DESTDIR=~/pure-data/Pd-0.43.4-extended-20130117 prefix= install (make sure the last line is all on one line) Now you should be able to go to ~/pure-data/Pd-0.43.4-extended-20130117/bin and run pd.exe and have a working Pd with jack (fingers crossed) .hc On 01/17/2013 05:40 PM, Esteban Viveros wrote: I need to run git clone git:// pure-data.git.sourceforge.net/gitroot/pure-data/pd-extended.git in the same folder of the libraries built? (~/pure-data/sources) In my case I need to do this with your script: (?) mkdir ~/auto-build cd ~/auto-buildhttps:// pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.43 pd-extended ~/auto-build/pd-extended/scripts/auto-build/pd-extended-auto-builder.sh 2013/1/17 Hans-Christoph Steiner h...@at.or.at Yeah, it looks like the binary installer for jack is all you need. No problem if you just built all the libraries in Building Library Dependencies For Windows From SVN '/Sources'. I was just trying to save you that effort, since its not needed for what you want to do. But now you are setup to build all of Pd-extended and perhaps even readanysf~ too :-D You will definitely need to download the Pd-extended source. .hc On 01/17/2013 03:37 PM, Esteban Viveros wrote: I have one more question... When you say to install Jack, you say the binary software or I need to find a source code of Jack audio? 2013/1/17 Esteban Viveros emvive...@gmail.com Ops... Already done... :/ Now only remains download pd source.. Did I that too wrong? I'm thinking to download the pd source and then run your script... Can I continue? 2013/1/17 Hans-Christoph Steiner h...@at.or.at You don't need that stuff at all for what you are doing, skip that step. That's only for building things like Gem. .hc On 01/16/2013 07:15 PM, Esteban Viveros wrote: Ok... Now I need to know where is pure-data directory..? It's needed to Building Library Dependencies For Windows From SVN '/Sources' 2013/1/16 Hans-Christoph Steiner h...@at.or.at I updated the makefile.mingw a bit, I forgot to add something before. Its attached. .hc On 01/16/2013 06:44 PM, Esteban Viveros wrote:
Re: [PD] Jack support on Windows
Ops... I tryied the option select all and the select with mouse feature are working now in cmd... 2013/1/20 Esteban Viveros emvive...@gmail.com Really Patrice... But How can I select the text?? I'm trying with the mouse but that's don't working here... 2013/1/19 Patrice Colet colet.patr...@free.fr Excuse the (... lot of letters..) but my cmd don't have ctrl+c option.. :/ hello, Are you really using cmd for compiling, or msys console? On cmd you can select and copy with menu actions, cygwin uses cmd... In msys console it's truly like a unix terminal, Ctrl+Insert and Shift+Insert for copying and pasting ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Esteban Viveros (27) 8815 7170 (27) 3066 0359 (11) 95761 4125 (11) 2738 7868 www.bandpage.com/estebanviveros http://soundcloud.com/estebanviveros https://www.facebook.com/estebanviveros.art http://www.papodecompositor-es.blogspot.com.br/ http://expurgacao.art.br/ -- Esteban Viveros (27) 8815 7170 (27) 3066 0359 (11) 95761 4125 (11) 2738 7868 www.bandpage.com/estebanviveros http://soundcloud.com/estebanviveros https://www.facebook.com/estebanviveros.art http://www.papodecompositor-es.blogspot.com.br/ http://expurgacao.art.br/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
On Sam, 2013-01-19 at 23:21 -0500, Ivica Ico Bukvic wrote: [...] pd-l2ork provides a solid, bug-free environment on Linux [...] Most of my GOP-abstractions are broken in pd-l2ork, because I often fit the GUI objects exactly into the GOP area. However, in pd-l2ork those iemguis don't show up, because of two reasons: * Compared the pd/pd-extended, the position of the iemguis is shifted by 2px to the right. This means they overlap the GOP area in pd-l2ork. * In pd-l2ork, iemguis aren't shown in the parent canvas when they perfectly fit into the GOP area. Only when there is a padding area of 3px width on the right side, they appear in the parent. Fitting iemguis perfectly into GOPs is not supported in pd-l2ork. I tried other stuff of mine and stumbled on some issues, though I didn't invest much into finding out what the causes are. One patch does not the connect to the server. It turned out, that the protocol test fails in pd-l2ork for some reason. When it loaded a certain abstraction, pd-l2ork startet to fully use the CPU and filling up the RAM until I killed the process (this is reproducible). Symbolboxes' support for german umlaute is broken. When typing 'blä' into: [symbol\ | [print] an empty line is printed to the console window (not even the 'print:' prefix shows up). messageboxes and other object classes seem not affected by this. [symbol blä(-[print] works fine. pd-l2ork certainly is in good shape, but calling it bug-free seems a bit sensationalistic. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Jack support on Windows
On 01/20/2013 01:50 PM, Esteban Viveros wrote: HC, can the compilation process gender a log file? i'm not HC, but hopefully i can give some hints. $ make make.log will redirect all stdout to make.log since most errors got to stderr, you probably want to do: $ make make.log 21 which will first redirect stderr to stdout, and then capture stdout to make.log. gfamsdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error installing via apt.puredata.info
I found the issue, it was a stupid mistake on my part. Thanks for troubleshooting it. I had cyclist in both Recommends: and Conflicts: Its fixed here: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16926 .hc On 01/19/2013 11:42 PM, Billy Stiltner wrote: yep running great now, that cyclist was tricky for some reason it would pop up back in the synaptic to be installed when selecting some other packages to be removed On Sat, Jan 19, 2013 at 10:48 PM, Billy Stiltner billy.stilt...@gmail.com wrote: i think it's gong on now, i had to remove all but puredata, pd-gui, and pd-utils(which asked me to remove ubuntustudio somethin another along with it when i tried to remove it haha) On Sat, Jan 19, 2013 at 10:33 PM, Billy Stiltner billy.stilt...@gmail.com wrote: billy@resonator:/usr/bin$ ls c* c++cctiff chkdupexe colcrt conjure.im6 csscombine_py2 c2ph ccttest chromium-browser collink convert cssparse c89ccxxmakechrt colormgr convert4chancssparse_py2 c89-gcccd-create-profile chsh colprof convert.im6 ctangle c99cd-fix-profile ciptoolcolrm corelistctanify c99-gcccdrdao cjpeg column cpanctanupload cabextract cdrecordckbcomp combinediff cpan2dist ctie calc++filt ckeygencomm cpanp ctstat calendar chacl ck-history command2foo2lava-pjl cpanp-run-perl cups-calibrate calfjackhost chage ck-launch-session compare cpp cupstestdsc calibrate_ppa chardet ck-list-sessions compare.im6 cpp-4.7 cupstestppd cancel charmap cksum compose crc32 curl captoinfo chartread clear composite c_rehashcut catchsegv chattr clear_console composite.im6 crontab cvlc catman chcon cmpconch csplit cvt cautious-launcher checkcites cmuwmtopbm conchftp csscapture cweave cb2ti3 check-language-support codepage config_data csscapture_py2 cc chfncolconjure csscombine billy@resonator:/usr/bin$ sudo apt-get install pd-extended Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: hyphen-en-us mythes-en-au openoffice.org-hyphenation Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: pd-extended 0 upgraded, 1 newly installed, 0 to remove and 198 not upgraded. Need to get 0 B/30.1 MB of archives. After this operation, 74.3 MB of additional disk space will be used. WARNING: The following packages cannot be authenticated! pd-extended Install these packages without verification [y/N]? y (Reading database ... 253288 files and directories currently installed.) Unpacking pd-extended (from .../pd-extended_0.43.1~20120926-1~quantal1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/pd-extended_0.43.1~20120926-1~quantal1_i386.deb (--unpack): trying to overwrite '/usr/bin/cyclist', which is also in package cyclist 0.1~alpha55-6 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/pd-extended_0.43.1~20120926-1~quantal1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) billy@resonator:/usr/bin$ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Raspberry Pi does denormals
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
Re: [PD] Question about controllers
The one I've seen the most with Pd is the Beringer BCF2000, but its not a keyboard, and I rarely use MIDI devices, so my info might be out of date. http://www.behringer.com/EN/Products/BCF2000.aspx .hc On 01/20/2013 02:26 AM, Mike McGonagle wrote: Hello, I am currently trying to rebuild a small home studio, and the next piece in my puzzle is a controller. I am looking at getting an Akai MPK49. But before I do, I was hoping someone might offer their experiences they might have in using it with PD. Or if you are using a similarly priced controller, I would also love to hear your thoughts. Thanks, Mike ___ 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] enhance pd-extended with pd-l2ork featues ?
Most of my GOP-abstractions are broken in pd-l2ork, because I often fit the GUI objects exactly into the GOP area. However, in pd-l2ork those iemguis don't show up, because of two reasons: * Compared the pd/pd-extended, the position of the iemguis is shifted by 2px to the right. This means they overlap the GOP area in pd-l2ork. * In pd-l2ork, iemguis aren't shown in the parent canvas when they perfectly fit into the GOP area. Only when there is a padding area of 3px width on the right side, they appear in the parent. Fitting iemguis perfectly into GOPs is not supported in pd-l2ork. They fit perfectly fine. It is that the original iemgui are inconsistent in positioning iemgui objects. Try auto-patching in regular pd various iemgui objects one below the other and you'll see how off they are. In other words, the regular pd lies about its x and sometimes y coordinates. It is just that this has been the case forever in pd that you accepted it as a norm. Granted, I completely understand why you would not want to mess with this but if you did (I went through this a couple months ago retrofitting everything I ever made for pd-l2ork and it was no fun), you'd end up with something that will be a lot more transportable over the long run than something that essentially compensates for a bug. I tried other stuff of mine and stumbled on some issues, though I didn't invest much into finding out what the causes are. One patch does not the connect to the server. It turned out, that the protocol test fails in pd-l2ork for some reason. When it loaded a certain abstraction, pd-l2ork startet to fully use the CPU and filling up the RAM until I killed the process (this is reproducible). It would be great to see what this is so that I can trace it down. Symbolboxes' support for german umlaute is broken. When typing 'blä' into: [symbol\ | [print] an empty line is printed to the console window (not even the 'print:' prefix shows up). messageboxes and other object classes seem not affected by this. [symbol blä(-[print] works fine. Can you send a patch so that this can be tested out? pd-l2ork certainly is in good shape, but calling it bug-free seems a bit sensationalistic. Indeed, claiming that every single 3rd-party external works is ridiculous and that is not what I've been referring to. I've been referring to the core (and I don't consider internationalization core yet since it is still a moving target both on l2ork and other iterations). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino download?
DNS troubles. Its fixed, but it might take a day or so to expire in your DNS cache. pduino is now also included in Pd-extended 0.43.4. .hc On 01/20/2013 03:01 AM, Phil Stone wrote: Hi Hans, Is this still the right link for downloading Pduino? http://at.or.at/hans/pd/Pduino-0.5.zip It's currently timing out (found on this page: http://puredata.info/downloads/pduino/releases/0.5). thanks, Phil Stone ___ 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] enhance pd-extended with pd-l2ork featues ?
$@ in msg box probably still crashes when incoming args 1000 (same with pd-extended) The only reason I implemented $@ was because you asked me to and then spent a couple hours making sure it worked on the new code base. I don't use that feature and apparently no one else does (since regular pd/extended don't even have it), so if anything this should not even be advertised as a feature... That said, you're absolutely right--this is a bug and I am glad that I am actually getting at least a few bug reports as a result of my provocative statement :-) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
[...] pd-l2ork provides a solid, bug-free environment [...] wow! Indeed, that statement should've had an asterisk next to it. By stable/solid/bug-free, I am referring here to the core not the entire ecosystem of 3rd party externals/features, many of which I've never used nor can I attest to... Time to eat my own words :-) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Mirroring physical patch cables in Pd
Hi all, Does anyone know of existing designs to mirror the state of physical patch cables in a Pd patch? In other words, I'm going to have an installation with a bunch of physical patch cables plugged in between various pods and I'd like them to control a Pd patch. So far I've been thinking I could generate different PWM signals at each unique cable source and measure them at each receiving socket, then send the graph data to the computer and use dynamic patching to control the patch. However, I'm wary of using dynamic patching in a production environment—any thoughts? Thanks all! —t3db0t ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Question about controllers
I haven't used a great deal of controllers, but I'm fond of the korg microkontrol, now sadly discontinued, although one is still able to get hold of it fairly easily. Fairly good, sturdy build quality (metal body), and nice range of different control types, quite similar to the akai one you mention being interested in. It also has some LCD displays, which the user can change the colour of and display eight-character strings on, when the controller is in what's called 'native mode'. The other advantage of this mode is that rotary encoders can be used in 'endless'/relative mode instead of 'absolute'. Anyway, I find it quite useful for PD-type stuff. (Incidentally, I have some pd code for working with this native mode, so let me know if you do end up using it and would be interested in this.) Hope that helps, J On Sun, Jan 20, 2013 at 4:24 PM, Hans-Christoph Steiner h...@at.or.at wrote: The one I've seen the most with Pd is the Beringer BCF2000, but its not a keyboard, and I rarely use MIDI devices, so my info might be out of date. http://www.behringer.com/EN/Products/BCF2000.aspx .hc On 01/20/2013 02:26 AM, Mike McGonagle wrote: Hello, I am currently trying to rebuild a small home studio, and the next piece in my puzzle is a controller. I am looking at getting an Akai MPK49. But before I do, I was hoping someone might offer their experiences they might have in using it with PD. Or if you are using a similarly priced controller, I would also love to hear your thoughts. Thanks, Mike ___ 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] Jack support on Windows
Ok, that's much better! Try the attached makefile.mingw. The problem is
actually here:
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `gcc -I../../pd/src -IC:\Program Files
(x86)/Jack/includes
-I/c/Progra~1/jack/includes -I/c/Progra~2/jack/includes
-I/c/Progra~3/jack/includes
Also, it looks like you're using cmd.exe, like I think patco said. You should
use the MinGW Shell, it is sometimes called MSYS. You can find it in your
Program Files menu under MinGW. Building Pd-extended might work under
cmd.exe, but I've never tried. I always use the MinGW MSYS shell.
.hc
On 01/20/2013 07:56 AM, Esteban Viveros wrote:
Finally! That's the result of my attempting compilation
C:\MinGW\msys\1.0\home\Esteban\pure-data\pd\srcmake -f makefile.mingw
makefile.mingw:300: makefile.dependencies: No such file or directory
gcc -I../../pd/src -IC:\Program Files (x86)/Jack/includes
-I/c/Progra~1/jack/inc
ludes -I/c/Progra~2/jack/includes -I/c/Progra~3/jack/includes
-I../../pd/portaud
io -I../../pd/portaudio/include -I../../pd/portaudio/src/common
-I../../pd/porta
udio/src/os/win -I../../pd/asio/ASIOSDK2/common
-I../../pd/asio/ASIOSDK2/host -I
../../pd/asio/ASIOSDK2/host/pc -DPD -DPD_INTERNAL -DPA_USE_ASIO
-DPA_USE_WMME -D
WINVER=0x0502 -DUSEAPI_MMIO -DUSEAPI_PORTAUDIO -mms-bitfields
-DWISHAPP='wish8
5.exe' -Wall -W -Wstrict-prototypes -Wno-unused -Wno-unused-parameter
-Wno-par
entheses -Wno-switch -O3 -funroll-loops -fomit-frame-pointer -M
g_canvas.c g_g
raph.c g_text.c g_rtext.c g_array.c g_template.c g_io.c g_scalar.c
g_traversal.
c g_guiconnect.c g_readwrite.c g_editor.c g_all_guis.c m_pd.c m_class.c
m_obj.
c m_atom.c m_memory.c m_binbuf.c m_conf_pdextended.c m_glob.c m_sched.c
s_main
.c s_inter.c s_file.c s_print.c s_loader.c s_path.c s_entry.c s_audio.c
s_midi.
c s_utf8.c d_ugen.c d_ctl.c d_arithmetic.c d_osc.c d_filter.c d_math.c
d_arra
y.c d_global.c d_delay.c d_resample.c x_arithmetic.c x_connective.c
x_acousti
cs.c d_soundfile.c e_fft.c e_gfxstub.c e_dac.c e_midi.c g_magicglass.c
scandi
r.c import.c path.c print.c closebang.c initbang.c loadbang.c
d_fft_mayer.c d_f
ftroutine.c s_audio_pa.c s_audio_paring.c s_audio_jack.c s_audio_mmio.c
s_midi_
mmio.c ../../pd/portaudio/src/common/pa_stream.c
../../pd/portaudio/src/common
/pa_trace.c ../../pd/portaudio/src/common/pa_process.c
../../pd/portaudio/src/
common/pa_front.c ../../pd/portaudio/src/common/pa_dither.c
../../pd/portaudio
/src/common/pa_cpuload.c ../../pd/portaudio/src/common/pa_converters.c
../../p
d/portaudio/src/common/pa_allocation.c
../../pd/portaudio/src/common/pa_ringbuf
fer.c ../../pd/portaudio/src/os/win/pa_win_hostapis.c
../../pd/portaudio/src/o
s/win/pa_win_util.c ../../pd/portaudio/src/os/win/pa_win_waveformat.c
../../pd
/portaudio/src/os/win/pa_win_coinitialize.c
../../pd/portaudio/src/hostapi/wmme
/pa_win_wmme.c g_all_guis.h m_imp.h g_canvas.h m_pd.h s_stuff.h
g_magicglass.h
s_audio_paring.h scandir.h ../portaudio/src/os/win/pa_win_coinitialize.h \
makefile.dependencies
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `gcc -I../../pd/src -IC:\Program Files
(x86)/Jack/includes
-I/c/Progra~1/jack/includes -I/c/Progra~2/jack/includes
-I/c/Progra~3/jack/inclu
des -I../../pd/portaudio -I../../pd/portaudio/include
-I../../pd/portaudio/src/c
ommon -I../../pd/portaudio/src/os/win -I../../pd/asio/ASIOSDK2/common
-I../../pd
/asio/ASIOSDK2/host -I../../pd/asio/ASIOSDK2/host/pc -DPD -DPD_INTERNAL
-DPA_USE
_ASIO -DPA_USE_WMME -DWINVER=0x0502 -DUSEAPI_MMIO -DUSEAPI_PORTAUDIO
-mms-bitfi
elds -DWISHAPP='wish85.exe' -Wall -W -Wstrict-prototypes -Wno-unused
-Wno-unu
sed-parameter -Wno-parentheses -Wno-switch -O3 -funroll-loops
-fomit-frame-poin
ter -M g_canvas.c g_graph.c g_text.c g_rtext.c g_array.c g_template.c
g_io.c g
_scalar.c g_traversal.c g_guiconnect.c g_readwrite.c g_editor.c
g_all_guis.c m
_pd.c m_class.c m_obj.c m_atom.c m_memory.c m_binbuf.c m_conf_pdextended.c
m_gl
ob.c m_sched.c s_main.c s_inter.c s_file.c s_print.c s_loader.c s_path.c
s_ent
ry.c s_audio.c s_midi.c s_utf8.c d_ugen.c d_ctl.c d_arithmetic.c d_osc.c
d_fil
ter.c d_math.c d_array.c d_global.c d_delay.c d_resample.c
x_arithmetic.c x_c
onnective.c x_acoustics.c d_soundfile.c e_fft.c e_gfxstub.c e_dac.c
e_midi.c
g_magicglass.c scandir.c import.c path.c print.c closebang.c initbang.c
loadba
ng.c d_fft_mayer.c d_fftroutine.c s_audio_pa.c s_audio_paring.c
s_audio_jack.c
s_audio_mmio.c s_midi_mmio.c ../../pd/portaudio/src/common/pa_stream.c
../../p
d/portaudio/src/common/pa_trace.c
../../pd/portaudio/src/common/pa_process.c .
./../pd/portaudio/src/common/pa_front.c
../../pd/portaudio/src/common/pa_dither
.c ../../pd/portaudio/src/common/pa_cpuload.c
../../pd/portaudio/src/common/pa
_converters.c ../../pd/portaudio/src/common/pa_allocation.c
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] enhance pd-extended with pd-l2ork featues ?
On 01/20/2013 06:36 AM, batinste wrote: I was intrigued by this [$@ bug (mainly because i didn't knew about this $@ thingy), so i decided to give it a try. Attached is my test patch. It crashes on my ubuntu 12.10 64bits, Pd-l2ork version 20130111 compiled 13:18:07 Jan 11 2013, way before reaching 1000 args. I launch it in my terminal with : ~$ pd-l2ork test-dollar-at.pd All i have to do is continuously move my mouse over the patch while it's running, and it will crash around 100 args. You can also try to play with the vslider, it will crash. OR (curiously), it won't crash when moving the mouse, but going in and out of edit mode or saving will make it crash... On a side note, look at the patch cord going out of the vslider : it looks weird to me, like attached a few pixels under the vslider, not directly connected to it. That's worth a bug report! It worked for me: I left it alone for a while and it went to 24817, then once I clicked in the patch, it crashed instantly. Batinste, could you file a bug report and include your patch? Ok now, the fun part : When i open this patch with pd-extended (Pd-0.43.4 (extended-20130118) compiled 09:30:52 Jan 18 2013), [list] only has one inlet (it should have 2, given that it's supposed to behave like [list append]) and when i want to see [list]'s help file, pd-ext opens bang's help file... When i open the same patch with pd-l2ork, the lists do have 2 inlets. Oh, and pd-extended happened to display lists with their 2 inlets, but i can't reproduce this reliably. I tried to open the patch with -noprefs (to ensure that i didn't have a forgotten [list] abstraction somewhere) same issue. Am i cursed or something ? I've never seen the [list] with the single inlet bug. Can you send me a patch to reproduce it? I think that would happen if you run 'pd-extended -nostartup' which will prevent the list lib from being automatically loaded at startup. -noprefs won't disable loading from ~/pd-externals or /usr/local/lib/pd-externals since that's hard coded in Pd. .hc On 20/01/2013 07:35, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Jonathan Wilkes' jancs...@yahoo.com; 'Hans-Christoph Steiner' h...@at.or.at Cc: pd-list@iem.at Sent: Saturday, January 19, 2013 11:21 PM Subject: RE: [PD] enhance pd-extended with pd-l2ork featues ? Why not simply use pd-l2ork? I do, but possible reasons why someone might not use Pd-l2ork: * no binary for windows * no binary for OSX On the flip-side pd-l2ork provides a solid, bug-free environment on Linux and looks a lot more contemporary than the aged default tk iteration. In other words, it is a targeted Linux distribution of pd (something that can be easily lost in a cross-platform effort with inadequate developer support, as I am sure Hans can attest to). At this point I would go as far as challenge you to find something that does not work or exhibits a buggy behavior $@ in msg box probably still crashes when incoming args 1000 (same with pd-extended) -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] Raspberry Pi does denormals
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/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
Hans, the info about NEON is relevant for armv7 (Beagleboard, Cubieboard, PengPod...). But Raspberry Pi doesn't have NEON. Float processing is done on coprocessor vfpv2. As far as I can see, vfpv2 hardly has any SIMD instructions (except for moving data between ARM and vfp). It is said to process a maximum of 8 single precision floats in parallel, but Raspberry Pi doesn't show a sign that it profits from data alignment, at least not when code is compiled with gcc. Katja On Sun, Jan 20, 2013 at 5:12 PM, Hans-Christoph Steiner h...@at.or.at 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 -
Re: [PD] enhance pd-extended with pd-l2ork featues ?
On Son, 2013-01-20 at 11:42 -0500, Ivica Ico Bukvic wrote: Most of my GOP-abstractions are broken in pd-l2ork, because I often fit the GUI objects exactly into the GOP area. However, in pd-l2ork those iemguis don't show up, because of two reasons: * Compared the pd/pd-extended, the position of the iemguis is shifted by 2px to the right. This means they overlap the GOP area in pd-l2ork. * In pd-l2ork, iemguis aren't shown in the parent canvas when they perfectly fit into the GOP area. Only when there is a padding area of 3px width on the right side, they appear in the parent. Fitting iemguis perfectly into GOPs is not supported in pd-l2ork. They fit perfectly fine. It is that the original iemgui are inconsistent in positioning iemgui objects. Try auto-patching in regular pd various iemgui objects one below the other and you'll see how off they are. In other words, the regular pd lies about its x and sometimes y coordinates. It is just that this has been the case forever in pd that you accepted it as a norm. Granted, I completely understand why you would not want to mess with this but if you did (I went through this a couple months ago retrofitting everything I ever made for pd-l2ork and it was no fun), you'd end up with something that will be a lot more transportable over the long run than something that essentially compensates for a bug. Ok, I see what you mean. When I align a hslider to a GOP area positioned at the coordinates 20 20, the hslider has the coordinates 23 20. It is wrong in Pd and Pd-extended. However, I don't quite see the advantage of fixing this, as it breaks portability of patches. I tried other stuff of mine and stumbled on some issues, though I didn't invest much into finding out what the causes are. One patch does not the connect to the server. It turned out, that the protocol test fails in pd-l2ork for some reason. When it loaded a certain abstraction, pd-l2ork startet to fully use the CPU and filling up the RAM until I killed the process (this is reproducible). It would be great to see what this is so that I can trace it down. If you want to have a look on your own, open chat.pd from netpd and click the 'unpatch' button. Here, on Ubuntu 12.04.1 with pd-l2ork from yesterday it immediately starts eating memory. You can download it from here: https://github.com/reduzent/netpd2/archive/master.zip Symbolboxes' support for german umlaute is broken. When typing 'blä' into: [symbol\ | [print] an empty line is printed to the console window (not even the 'print:' prefix shows up). messageboxes and other object classes seem not affected by this. [symbol blä(-[print] works fine. Can you send a patch so that this can be tested out? Actually no, since it doesn't trigger the problem when I save the symbol containing non-ASCII characters in the patch. You really have to type them in order to trigger the issue. To illustrate the problem, I typed 'äöü' to a symbol box and save the result with [textfile]. I did the same with a message box. The results are indeed different. Here the content of the files (in hex): * from symbol box: E4 F6 FC 3B 0A * from message box: C3 A4 C3 B6 C3 BC 3B 0A Obviously, symbol box writes in latin1 encoding, while message box (and probably the rest of Pd-l2ork) writes in proper utf-8. BTW, my locale is set to LANG=en_US.UTF-8. pd-l2ork certainly is in good shape, but calling it bug-free seems a bit sensationalistic. Indeed, claiming that every single 3rd-party external works is ridiculous and that is not what I've been referring to. I've been referring to the core (and I don't consider internationalization core yet since it is still a moving target both on l2ork and other iterations). I didn't mention any issues with internationalization. If you think that my problem with German umlaute has something to do with internationalization, we disagree. I would consider proper UTF-8 support a core feature. IMHO, even claiming only the core to be bug-free is a bit bold. That said, doubting the bug-freeness of your work doesn't mean to make you or Pd-l2ork appear in a bad light at all. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error installing via apt.puredata.info
This 'mode of installation' issue is interesting. I've been able to successfully install pd-extended yet, via the Software Centre in Ubuntu Oneiric, by right-clicking on the .deb file and opening with Software Centre. I've yet to try installing via Synaptic. And yet to try this method below. Before I do either, I believe I must uninstall all vanilla pd, using apt-get remove, and de-installing all related pd packages in Synaptic. So this comment was interesting, which I found in the pd forum here, http://puredata.hurleur.com/viewtopic.php?pid=33184#p33184 It suggests using dpkg to install with, so that any missing dependencies are reported. vis; cd /folder/with/download/package sudo dpkg -i pd-extended.deb -Original Message- From: Hans-Christoph Steiner h...@at.or.at To: Billy Stiltner billy.stilt...@gmail.com, Pd List pd-list@iem.at Subject: Re: [PD] error installing via apt.puredata.info Date: Sun, 20 Jan 2013 10:31:41 -0500 I found the issue, it was a stupid mistake on my part. Thanks for troubleshooting it. I had cyclist in both Recommends: and Conflicts: Its fixed here: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16926 .hc On 01/19/2013 11:42 PM, Billy Stiltner wrote: yep running great now, that cyclist was tricky for some reason it would pop up back in the synaptic to be installed when selecting some other packages to be removed On Sat, Jan 19, 2013 at 10:48 PM, Billy Stiltner billy.stilt...@gmail.com wrote: i think it's gong on now, i had to remove all but puredata, pd-gui, and pd-utils(which asked me to remove ubuntustudio somethin another along with it when i tried to remove it haha) On Sat, Jan 19, 2013 at 10:33 PM, Billy Stiltner billy.stilt...@gmail.com wrote: billy@resonator:/usr/bin$ ls c* c++cctiff chkdupexe colcrt conjure.im6 csscombine_py2 c2ph ccttest chromium-browser collink convert cssparse c89ccxxmakechrt colormgr convert4chancssparse_py2 c89-gcccd-create-profile chsh colprof convert.im6 ctangle c99cd-fix-profile ciptoolcolrm corelistctanify c99-gcccdrdao cjpeg column cpanctanupload cabextract cdrecordckbcomp combinediff cpan2dist ctie calc++filt ckeygencomm cpanp ctstat calendar chacl ck-history command2foo2lava-pjl cpanp-run-perl cups-calibrate calfjackhost chage ck-launch-session compare cpp cupstestdsc calibrate_ppa chardet ck-list-sessions compare.im6 cpp-4.7 cupstestppd cancel charmap cksum compose crc32 curl captoinfo chartread clear composite c_rehashcut catchsegv chattr clear_console composite.im6 crontab cvlc catman chcon cmpconch csplit cvt cautious-launcher checkcites cmuwmtopbm conchftp csscapture cweave cb2ti3 check-language-support codepage config_data csscapture_py2 cc chfncolconjure csscombine billy@resonator:/usr/bin$ sudo apt-get install pd-extended Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: hyphen-en-us mythes-en-au openoffice.org-hyphenation Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: pd-extended 0 upgraded, 1 newly installed, 0 to remove and 198 not upgraded. Need to get 0 B/30.1 MB of archives. After this operation, 74.3 MB of additional disk space will be used. WARNING: The following packages cannot be authenticated! pd-extended Install these packages without verification [y/N]? y (Reading database ... 253288 files and directories currently installed.) Unpacking pd-extended (from .../pd-extended_0.43.1~20120926-1~quantal1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/pd-extended_0.43.1~20120926-1~quantal1_i386.deb (--unpack): trying to overwrite '/usr/bin/cyclist', which is also in package cyclist 0.1~alpha55-6 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/pd-extended_0.43.1~20120926-1~quantal1_i386.deb E: Sub-process /usr/bin/dpkg
Re: [PD] [Bulk] Re: enhance pd-extended with pd-l2ork featues ?
On 20/01/2013 21:02, Hans-Christoph Steiner wrote: On 01/20/2013 06:36 AM, batinste wrote: I was intrigued by this [$@ bug (mainly because i didn't knew about this $@ thingy), so i decided to give it a try. Attached is my test patch. It crashes on my ubuntu 12.10 64bits, Pd-l2ork version 20130111 compiled 13:18:07 Jan 11 2013, way before reaching 1000 args. I launch it in my terminal with : ~$ pd-l2ork test-dollar-at.pd All i have to do is continuously move my mouse over the patch while it's running, and it will crash around 100 args. You can also try to play with the vslider, it will crash. OR (curiously), it won't crash when moving the mouse, but going in and out of edit mode or saving will make it crash... On a side note, look at the patch cord going out of the vslider : it looks weird to me, like attached a few pixels under the vslider, not directly connected to it. That's worth a bug report! It worked for me: I left it alone for a while and it went to 24817, then once I clicked in the patch, it crashed instantly. Batinste, could you file a bug report and include your patch? ok ! Ok now, the fun part : When i open this patch with pd-extended (Pd-0.43.4 (extended-20130118) compiled 09:30:52 Jan 18 2013), [list] only has one inlet (it should have 2, given that it's supposed to behave like [list append]) and when i want to see [list]'s help file, pd-ext opens bang's help file... When i open the same patch with pd-l2ork, the lists do have 2 inlets. Oh, and pd-extended happened to display lists with their 2 inlets, but i can't reproduce this reliably. I tried to open the patch with -noprefs (to ensure that i didn't have a forgotten [list] abstraction somewhere) same issue. Am i cursed or something ? I've never seen the [list] with the single inlet bug. Can you send me a patch to reproduce it? I think that would happen if you run 'pd-extended -nostartup' which will prevent the list lib from being automatically loaded at startup. -noprefs won't disable loading from ~/pd-externals or /usr/local/lib/pd-externals since that's hard coded in Pd. .hc oops my bad, i did not see this : error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It was with the patch i attached earlier. On 20/01/2013 07:35, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Jonathan Wilkes' jancs...@yahoo.com; 'Hans-Christoph Steiner' h...@at.or.at Cc: pd-list@iem.at Sent: Saturday, January 19, 2013 11:21 PM Subject: RE: [PD] enhance pd-extended with pd-l2ork featues ? Why not simply use pd-l2ork? I do, but possible reasons why someone might not use Pd-l2ork: * no binary for windows * no binary for OSX On the flip-side pd-l2ork provides a solid, bug-free environment on Linux and looks a lot more contemporary than the aged default tk iteration. In other words, it is a targeted Linux distribution of pd (something that can be easily lost in a cross-platform effort with inadequate developer support, as I am sure Hans can attest to). At this point I would go as far as challenge you to find something that does not work or exhibits a buggy behavior $@ in msg box probably still crashes when incoming args 1000 (same with pd-extended) -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
[PD] libpd netreceive
Hi all, i am new to libpd and i have run into problems using netreceive on ios 5.1. While netsend works perfectly, netreceive doesn't work at all. Senders can connect to the receiving socket, but netreceive wouldn't spit out any data. Looking at the code, it seems to me that the polling of the net sockets (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in libpd at all. I also couldn't find a different place where this is done. Does that mean that libpd doesn't currently service incoming socket data? Thanks for clarification, all the best, gr~~~ -- Thomas Grill http://g.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Re: enhance pd-extended with pd-l2ork featues ?
On Jan 20, 2013, at 5:52 PM, batinste wrote: On 20/01/2013 21:02, Hans-Christoph Steiner wrote: On 01/20/2013 06:36 AM, batinste wrote: I was intrigued by this [$@ bug (mainly because i didn't knew about this $@ thingy), so i decided to give it a try. Attached is my test patch. It crashes on my ubuntu 12.10 64bits, Pd-l2ork version 20130111 compiled 13:18:07 Jan 11 2013, way before reaching 1000 args. I launch it in my terminal with : ~$ pd-l2ork test-dollar-at.pd All i have to do is continuously move my mouse over the patch while it's running, and it will crash around 100 args. You can also try to play with the vslider, it will crash. OR (curiously), it won't crash when moving the mouse, but going in and out of edit mode or saving will make it crash... On a side note, look at the patch cord going out of the vslider : it looks weird to me, like attached a few pixels under the vslider, not directly connected to it. That's worth a bug report! It worked for me: I left it alone for a while and it went to 24817, then once I clicked in the patch, it crashed instantly. Batinste, could you file a bug report and include your patch? ok ! Ok now, the fun part : When i open this patch with pd-extended (Pd-0.43.4 (extended-20130118) compiled 09:30:52 Jan 18 2013), [list] only has one inlet (it should have 2, given that it's supposed to behave like [list append]) and when i want to see [list]'s help file, pd-ext opens bang's help file... When i open the same patch with pd-l2ork, the lists do have 2 inlets. Oh, and pd-extended happened to display lists with their 2 inlets, but i can't reproduce this reliably. I tried to open the patch with -noprefs (to ensure that i didn't have a forgotten [list] abstraction somewhere) same issue. Am i cursed or something ? I've never seen the [list] with the single inlet bug. Can you send me a patch to reproduce it? I think that would happen if you run 'pd-extended -nostartup' which will prevent the list lib from being automatically loaded at startup. -noprefs won't disable loading from ~/pd-externals or /usr/local/lib/pd-externals since that's hard coded in Pd. .hc oops my bad, i did not see this : error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It was with the patch i attached earlier. Where you able to fix that error? That file is definitely included in the packages that I've tried. .hc On 20/01/2013 07:35, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Jonathan Wilkes' jancs...@yahoo.com; 'Hans-Christoph Steiner' h...@at.or.at Cc: pd-list@iem.at Sent: Saturday, January 19, 2013 11:21 PM Subject: RE: [PD] enhance pd-extended with pd-l2ork featues ? Why not simply use pd-l2ork? I do, but possible reasons why someone might not use Pd-l2ork: * no binary for windows * no binary for OSX On the flip-side pd-l2ork provides a solid, bug-free environment on Linux and looks a lot more contemporary than the aged default tk iteration. In other words, it is a targeted Linux distribution of pd (something that can be easily lost in a cross-platform effort with inadequate developer support, as I am sure Hans can attest to). At this point I would go as far as challenge you to find something that does not work or exhibits a buggy behavior $@ in msg box probably still crashes when incoming args 1000 (same with pd-extended) -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] 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] libpd netreceive
Hi Thomas, I have to admit that I didn't realize that netreceive requires an extra polling step. So, I'm afraid that netreceive is currently broken. The question is what to do about this. I took a quick look at sys_domicrosleep and didn't immediately see how it works. I wouldn't mind integrating it into libpd somehow, but I want to be sure that there won't be any weird side effects. This seems slightly off-topic for pd-list. Shall we talk about this on pd-dev? Cheers, Peter On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill g...@g.org wrote: Hi all, i am new to libpd and i have run into problems using netreceive on ios 5.1. While netsend works perfectly, netreceive doesn't work at all. Senders can connect to the receiving socket, but netreceive wouldn't spit out any data. Looking at the code, it seems to me that the polling of the net sockets (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in libpd at all. I also couldn't find a different place where this is done. Does that mean that libpd doesn't currently service incoming socket data? Thanks for clarification, all the best, gr~~~ -- 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
Re: [PD] enhance pd-extended with pd-l2ork featues ?
On Son, 2013-01-20 at 11:42 -0500, Ivica Ico Bukvic wrote: Most of my GOP-abstractions are broken in pd-l2ork, because I often fit the GUI objects exactly into the GOP area. However, in pd-l2ork those iemguis don't show up, because of two reasons: * Compared the pd/pd-extended, the position of the iemguis is shifted by 2px to the right. This means they overlap the GOP area in pd-l2ork. * In pd-l2ork, iemguis aren't shown in the parent canvas when they perfectly fit into the GOP area. Only when there is a padding area of 3px width on the right side, they appear in the parent. Fitting iemguis perfectly into GOPs is not supported in pd-l2ork. They fit perfectly fine. It is that the original iemgui are inconsistent in positioning iemgui objects. Try auto-patching in regular pd various iemgui objects one below the other and you'll see how off they are. In other words, the regular pd lies about its x and sometimes y coordinates. It is just that this has been the case forever in pd that you accepted it as a norm. Granted, I completely understand why you would not want to mess with this but if you did (I went through this a couple months ago retrofitting everything I ever made for pd-l2ork and it was no fun), you'd end up with something that will be a lot more transportable over the long run than something that essentially compensates for a bug. Ok, I see what you mean. When I align a hslider to a GOP area positioned at the coordinates 20 20, the hslider has the coordinates 23 20. It is wrong in Pd and Pd-extended. However, I don't quite see the advantage of fixing this, as it breaks portability of patches. The problem with portability is the longer you wait the less code is actually editable. This is because more of it becomes encumbered by bugs that cannot be removed due to users' growing library of prior code they wish to use and that keeps them tied to a product that perpetuates such inconsistencies. I think this is why in great part pd development has become exponentially more complex, not because of lack of developers, per se, but because of insurmountable task of ensuring that there is no breakage of backwards compatibility, even though some of those means simply perpetuating buggy behavior. My motto is if it is a bug it needs to be fixed and the sooner this is done the better for everyone involved. How does this particular issue this matter? Due to misaligned drawing, mouse hover is mis-detected by a few pixels, so selecting and interacting with objects, or showing tooltips is out of whack. More so, autopatching is broken without a workaround pd-l2ork used to have which was an ugly hack that further obfuscated the code base. So, this is not just a usability issue, but also a maintainability issue. If you have copious amounts of abstractions, there is always a way to build a script that would change position of all iemgui objects according to their inconsistency and this would likely save you a lot of trouble. Personally, I found it a lot easier to simply edit abstractions--while I had a fair amount of them, I still tend not to trust quickly hacked shell scripts without extensive testing which in the end seemed to me at least more time consuming than doing this simply by hand... It would be great to see what this is so that I can trace it down. If you want to have a look on your own, open chat.pd from netpd and click the 'unpatch' button. Here, on Ubuntu 12.04.1 with pd-l2ork from yesterday it immediately starts eating memory. You can download it from here: https://github.com/reduzent/netpd2/archive/master.zip Great! Thanks for sharing. I will look into this asap. Just to make sure, the code above does not use any third-party externals, correct? Symbolboxes' support for german umlaute is broken. When typing 'blä' into: [symbol\ | [print] an empty line is printed to the console window (not even the 'print:' prefix shows up). messageboxes and other object classes seem not affected by this. [symbol blä(-[print] works fine. Can you send a patch so that this can be tested out? Actually no, since it doesn't trigger the problem when I save the symbol containing non-ASCII characters in the patch. You really have to type them in order to trigger the issue. To illustrate the problem, I typed 'äöü' to a symbol box and save the result with [textfile]. I did the same with a message box. The results are indeed different. Here the content of the files (in hex): * from symbol box: E4 F6 FC 3B 0A * from message box: C3 A4 C3 B6 C3 BC 3B 0A Obviously, symbol box writes in latin1 encoding, while message box (and probably the rest of Pd-l2ork) writes in proper utf-8. BTW, my locale is set to LANG=en_US.UTF-8. Interesting. Thanks for reporting. Like I mentioned, I recently introduced *initial* UTF support which by no means meant exhaustive support. This should not
Re: [PD] libpd netreceive
Peter while you are in here, i'm wondering about using the latest libpd on linux, would it be better to use the old code or the latest? is there anything that doesn't work that didn't work in the previous versions? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Mirroring physical patch cables in Pd
On 01/20/2013 12:08 PM, Tedb0t wrote: Hi all, Does anyone know of existing designs to mirror the state of physical patch cables in a Pd patch? In other words, I'm going to have an installation with a bunch of physical patch cables plugged in between various pods and I'd like them to control a Pd patch. hey tedbot, You could also just play sine waves thru them and then feed all signals to a set of bandpass filters. Measure the amplitude of the filtered signals and you know which one you have. But perhaps your PWM technique would use less CPU, if that's an issue. So far I've been thinking I could generate different PWM signals at each unique cable source and measure them at each receiving socket, then send the graph data to the computer and use dynamic patching to control the patch. However, I'm wary of using dynamic patching in a production environment—any thoughts? you can just have a set of pre-loaded patches and switch between them using [switch~]. I've used that with good results in a production environment. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd netreceive
Hi Billy, Use the latest version. I don't think we've had any regressions. Peter On Sun, Jan 20, 2013 at 9:52 PM, Billy Stiltner billy.stilt...@gmail.comwrote: Peter while you are in here, i'm wondering about using the latest libpd on linux, would it be better to use the old code or the latest? is there anything that doesn't work that didn't work in the previous versions? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
- Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Roman Haefeli' reduz...@gmail.com; pd-list@iem.at Cc: Sent: Sunday, January 20, 2013 9:30 PM Subject: Re: [PD] enhance pd-extended with pd-l2ork featues ? [...] Even based on all that has transpired since, the reports we've gotten so far are: 1) $@ issue which IMHO is a non-issue since I don't consider this a feature I wish to advertise as a feature just yet (for exact reasons why it was brought up) 2) UTF inconsistency you reported that is a genuine bug 3) iemgui positioning which I would consider (IMHO) a fix, not a bug All in all, AFAICT this leaves us with #2. Also see the end of: http://www.youtube.com/watch?v=wTPZxcgWoI0 When undoing the creation of an object or objects, at some point Pd-l2ork will move the object to the place where the mouse happened to be hovering when the user clicked ctrl-1 to get an empty box dangling from the mouse. But the user never actually anchored the object there-- they only anchored it somewhere once they clicked the mouse button. Thus, your undo history erroneously adds an object placement event that was never performed by the user in the first place. Theoretically the corresponding undo event should make the object dangle from the mouse again, but that's of very little practical value and would just bloat the undo history with an extra step for every object in the chain. Instead this event should simply not be added to the undo history. I don't know the innards of pd well, but those dangle events should all have a single 0 as a coordinate so maybe you can check for that. -Jonathan Best wishes, Ico 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] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
- Original Message - From: Billy Stiltner billy.stilt...@gmail.com To: IOhannes zmölnig zmoel...@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice. What about the -guicmd cmd... flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on localhost? Then you could just write the interface with html5 canvas, svg, javascript, or whatever. -Jonathan http://lists.puredata.info/pipermail/pd-list/2011-03/087772.html ___ 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] Search plugin update
I updated the homepage of the search plugin to point to a pd glossary that I wrote awhile back and forgot about. It's kind of neat-- you can add entries to the text file in doc/5.reference/glossary.txt and doc/5.reference/glossary.pd will parse the file, sort the entries in alphabetical order, and display them in the patch with links to objects related to the terms. They probably need some work so feel free to make/ suggest changes. Unfortunately ctrl-f Find won't scroll to the relevant part of a long patch if the match happens to be out of view. Is there a way to fix this? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
On 01/21/2013 12:15 AM, Jonathan Wilkes wrote: Also see the end of: http://www.youtube.com/watch?v=wTPZxcgWoI0 When undoing the creation of an object or objects, at some point Pd-l2ork will move the object to the place where the mouse happened to be hovering when the user clicked ctrl-1 to get an empty box dangling from the mouse. But the user never actually anchored the object there-- they only anchored it somewhere once they clicked the mouse button. Thus, your undo history erroneously adds an object placement event that was never performed by the user in the first place. Theoretically the corresponding undo event should make the object dangle from the mouse again, but that's of very little practical value and would just bloat the undo history with an extra step for every object in the chain. Instead this event should simply not be added to the undo history. I don't know the innards of pd well, but those dangle events should all have a single 0 as a coordinate so maybe you can check for that. -Jonathan That is not a bug. That is how pd instantiates objects. As soon as your cursor touches canvas, it will instantiate an object at the last known cursor position (if the cursor is off-canvas) or next to mouse cursor and then enable motion for the object to follow the cursor until a mouse clicks (there is an exception when autopatching in which case motion is not enabled, but that is not relevant to this example). So, if you create an object without having a mouse on canvas, then move mouse onto it, the object will instantiate where you had your cursor the last time and then immediately move (since the startmotion was triggered) next to your cursor once you've positioned it back over the canvas. So, in essence there are 2 steps undo is keeping track of. Yes, this addition adds extra step but is a lot easier to manage than coming up with yet another exception on how the editing works. Doing what you suggest could easily obliterate undo and annoy user when they do series of undos and then suddently the object is back hooked onto mouse and the next thing you know, the undo has rebranched since it assumes that the user is now wanting to do something new from that spot onwards making them lose forward undo history. This is all because pd first instantiates objects, then asks question where the object should go. While ideally this one step could be skipped, it would require a fairly hefty rewrite for a mere skip of one undo step... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
yeah i have an html javascript java socket interface to my fractal sequencer that draws the fractal that the orbits are being generated from. the only thing i'm sending though is the mouse position which is translated to the fractal space coordinates so the patch can spit out the orbits from that point as well as a zoom feature to zoom in and also a switch to switch from mandelbrot to burningshipx or burningshipy. i do not use the -guicmd or pdnogui yet but plan on using something like that to develop simple tutorials On Mon, Jan 21, 2013 at 12:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Billy Stiltner billy.stilt...@gmail.com To: IOhannes zmölnig zmoel...@iem.at Cc: pd-list@iem.at Sent: Sunday, January 20, 2013 10:04 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released haha , last month i tried to install juce to see about making an alternate graphics front end to my patches. there was some weirdness in the way you compile it then run the introjucer or somethin to update it then after the update something didn't quite work right. then there are all the old projects that use the old steinberg vst sdk which you cant get from steinberg anymore so all that is just awful. i think that there should be a really nice updated version of juce either available now or in the near future. its a tossup between fltk, qt , opengl ,juce, and processing. i just want to be able to add my waveform data filenames to the presets with a fileopen dialog without using an external, string parsing like .scl files that have 100.00 or 3/2, and polyphonic patchcords would be nice. What about the -guicmd cmd... flag? Could one write a pd-gui.html that lives at localhost:1234, and have it talk to pd at its port on localhost? Then you could just write the interface with html5 canvas, svg, javascript, or whatever. -Jonathan http://lists.puredata.info/pipermail/pd-list/2011-03/087772.html ___ 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] enhance pd-extended with pd-l2ork featues ?
On 01/20/2013 04:35 PM, Roman Haefeli wrote: If you want to have a look on your own, open chat.pd from netpd and click the 'unpatch' button. Here, on Ubuntu 12.04.1 with pd-l2ork from yesterday it immediately starts eating memory. You can download it from here: https://github.com/reduzent/netpd2/archive/master.zip snip Actually no, since it doesn't trigger the problem when I save the symbol containing non-ASCII characters in the patch. You really have to type them in order to trigger the issue. To illustrate the problem, I typed 'äöü' to a symbol box and save the result with [textfile]. I did the same with a message box. The results are indeed different. Here the content of the files (in hex): * from symbol box: E4 F6 FC 3B 0A * from message box: C3 A4 C3 B6 C3 BC 3B 0A Obviously, symbol box writes in latin1 encoding, while message box (and probably the rest of Pd-l2ork) writes in proper utf-8. BTW, my locale is set to LANG=en_US.UTF-8. BTW, both of these have been fixed in the latest git snapshot (binaries should be avilable soon via online downloads). Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
