[PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...
Feature Requests item #3578019, was opened at 2012-10-18 00:39 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3578019&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: I'd like to... Initial Comment: ..know if it is possible to use other than "2^n"-blocksizes?! You know, I've read about that, and now I wonder if the info or the implementation is bugged.. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3578019&group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...
Hi, On 18/10/12 08:39, SourceForge.net wrote: Feature Requests item #3578019, was opened at 2012-10-18 00:39 It's already implemented... Submitted By: Nobody/Anonymous (nobody) Summary: I'd like to... Initial Comment: ..know if it is possible to use other than "2^n"-blocksizes?! Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate). You know, I've read about that, and now I wonder if the info or the implementation is bugged.. Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached. Note that dsp must be on globally, but switched off for the particular canvas, for this to make sense. Also bang->switch~ seems to compute a dsp block immediately, so remember to use trigger when applicable to initialise your signal objects in that patch. Perhaps it wouldn't hurt to have a small example somewhat along these lines in the help patch. Claude -- http://mathr.co.uk #N canvas 0 0 450 300 10; #X obj 101 103 switch~ 12345; #X obj 108 134 noise~; #X obj 108 155 tabwrite~ \$0-noise; #X obj 55 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 100 50 loadbang; #X msg 100 71 0; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-noise 12345 float 0; #X coords 0 1 12344 -1 200 140 1; #X restore 238 82 graph; #X msg 183 17 \; pd dsp 1; #X obj 56 84 t b b; #X connect 1 0 2 0; #X connect 3 0 8 0; #X connect 4 0 5 0; #X connect 5 0 0 0; #X connect 8 0 0 0; #X connect 8 1 2 0; ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...
Hi, On 18/10/12 08:39, SourceForge.net wrote: Feature Requests item #3578019, was opened at 2012-10-18 00:39 It's already implemented... Submitted By: Nobody/Anonymous (nobody) Summary: I'd like to... Initial Comment: ..know if it is possible to use other than "2^n"-blocksizes?! Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate). You know, I've read about that, and now I wonder if the info or the implementation is bugged.. Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached. Note that dsp must be on globally, but switched off for the particular canvas, for this to make sense. Also bang->switch~ seems to compute a dsp block immediately, so remember to use trigger when applicable to initialise your signal objects in that patch. Perhaps it wouldn't hurt to have a small example somewhat along these lines in the help patch. Claude -- http://mathr.co.uk #N canvas 0 0 450 300 10; #X obj 101 103 switch~ 12345; #X obj 108 134 noise~; #X obj 108 155 tabwrite~ \$0-noise; #X obj 55 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 100 50 loadbang; #X msg 100 71 0; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-noise 12345 float 0; #X coords 0 1 12344 -1 200 140 1; #X restore 238 82 graph; #X msg 183 17 \; pd dsp 1; #X obj 56 84 t b b; #X connect 1 0 2 0; #X connect 3 0 8 0; #X connect 4 0 5 0; #X connect 5 0 0 0; #X connect 8 0 0 0; #X connect 8 1 2 0; ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-3578095 ] netreceive doesn't work in batch mode
Bugs item #3578095, was opened at 2012-10-18 06:12 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3578095&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: netreceive doesn't work in batch mode Initial Comment: [netreceive] in -batch mode doesn't work, it binds the port but doesn't seem to output anything. netstat shows a large receive queue, which presumably contains my incoming data. $ pd -batch my-netreceive-r.pd & ... $ netstat -au Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp75264 0 *:5### *:* ... $ pd -version Pd version 0.42-6 compiled 13:48:58 Feb 17 2012 My specific use case is "one core for as-fast-as-possible analysis of an dsp system's parameter space, another for realtime/live audio, communicating via loopback network ", which perhaps is too far from the realms of sanity? Some awkward workarounds spring to mind using -nogui instead (using a switch~'d off wrapper patch and bang it when I want dsp to run; or using a very high upsampling ratio and compensating any input to objects that use the samplerate, ...) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3578095&group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-3577728 ] menu edit - undo & redo command error
Patches item #3577728, was opened at 2012-10-16 14:22 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3577728&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: pd-extended >Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Miller Puckette (millerpuckette) Summary: menu edit - undo & redo command error Initial Comment: Pd-extended 0.43.1, Windows 7 64, Intel Core i7 Undo and redo command from edit menu show this error message: wrong # args: should be "menu_undo" wrong # args: should be "menu_undo" while executing "menu_undo $::focused_window" (menu invoke) wrong # args: should be "menu_redo" wrong # args: should be "menu_redo" while executing "menu_redo $::focused_window" (menu invoke) CTRL+Z and SHIFT+CTRL+Z works well -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3577728&group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
Any objections? Shall I go with lazy consensus on this one? .hc On 10/16/2012 07:17 PM, Hans-Christoph Steiner wrote: > > Hey all, > > I was tired of dealing with a cryptic ./configure, so I converted OSCx > to be based on the Library Template. THis is currently in the > pd-extended/0.43 branch. > > Anyone have any objections of me removing the old OSCx and replacing it > with the 'oscx' library? > > .hc > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
