Re: [PD] Open midi files in PD Vanilla?
We faced this at RjDj a while back. Me and Joe and Frank and the guys worked on something to make text files from MIDI, they could be fed to a vanilla style list sequencer. Worked quite well IIRC. Maybe its still in the rj library. a. On Mon, Aug 13, 2012 at 04:42:20PM +0200, Filippo Beck Peccoz wrote: Hi list, copying here a puredata forum post which remained unanswered- hope someone can help :) after searching around the forums and the net I decided to post this question here.. I'm using PD as the audio engine for a mobile game (using libpd, and therefore only Vanilla objects). This is very exciting, and I'm exploring all the possibilities for composition and realtime sound generation. One big thing I wanted to include is the possibility of reading midi files inside the patch, and pipe the data to envelopes and oscillators accordingly. Extended apparently has the seq object, but how about Vanilla? Is there a way to import a .mid file into a patch? Thank you all for helping a greenhorn out :=) Filippo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Fifteen Student Pure Data Projects
Thanks to you and your students for sharing these Leanord! On Fri, Aug 10, 2012 at 03:12:41PM -0700, Freaky DNA wrote: Greetings all, I have just posted a collection of student patches ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Cross Compiling External for Windows - Problem
Output: i686-pc-mingw32-gcc -I/home/thomas/src/Pd-0.42.5-extended/pd-win/include/pd -std=c99 re, how to get information about the linker used, and how to set it in the Makefile. That was part of the original question, try to put this in LDFLAGS or LIBS -Wl,--verbose to make linker more talkative... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd Vanilla on Raspberry Pi
Hi everyone, I got this info about the anolog audio output being cheap PWM with filtering from this thread : http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28t=8684 I'm assuming these guys know what they're talking about (I think the first reply metioning this is by a member of the Raspberry Pi team. Cheers, Pierre 2012/8/14 Michael Zacherl sdiy-m...@blauwurf.info On 14.8.2012, at 01:47 , Miller Puckette wrote: Thanks for the info... some quick ideas: good to know but that didn't help. I can't tell what it is but apparently it's a timing or order of execution issue at startup in batch-mode: Delaying the ; pd dsp 1 message by 200ms helps avoiding the device busy error. Same patch loaded in the gui, no problem. :-\ According to 'top' the cpu load drops from 75% to about 70% with -nogui for a 4k-window. Just about enough to avoid glitching. But any system activity brings the sound to a halt for a short moment. So that was just an ssh-session and Pd running in batch-mode. At some point I'll go through this and see what can be done: http://puredata.info/community/pdwiki/Optimize/ BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible. Yep: the message is ; pd quit ah, of course! thanks, Michael. -- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist ___ 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] variable number of outlets/inlets
If the inlets/outlets are on the outside of your abstraction make sure you use [initbang]. Otherwise the connections to those ports in your main patch wouldn't be created. Michael. On 14.8.2012, at 11:15 , João Pais wrote: with dynamic patching, for example [jmmmp/dacm~] in Pd-extended. not exactly what you asked, but similar. João Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad -- noise chasers: http://blauwurf.at http://soundcloud.com/noiseconformist ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets
On Fri, 10 Aug 2012 22:28:53 +0200, Eldad Tsabary tazberry_d...@yahoo.ca wrote: Hi, How does one create an abstraction with a variable number of outlets (depending on the number of arguments)? Thanks Eldad ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list You can use [tof/arguments] to count the amount of arguments. Then, do dynamic patching. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
On 08/11/2012 01:58 PM, Michael Zacherl wrote: In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not, the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)). unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib). instead, there is a (low-level) patch for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla). thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here) fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
On 08/11/2012 01:58 PM, Michael Zacherl wrote: In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not, the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)). unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib). instead, there is a (low-level) patch for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla). thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd- extended (only the core binary, no need for any externals here) fgmasdr IOhannes Also, if you need a pre-loadbang event which happens right before loadbang but after all the objects have loaded, you could try pd-l2ork which has also pre-loadbang event. Currently it is only being used for universal presets that depend on the graph placement of all objects to keep track of them. Therefore, the only time for the presets to detect objects they are tied to correctly is only after they have all been created but before loadbang (as one could loadbang a new preset which would not work unless all the objects have been paired properly). The reason preset_hub and preset_node do this is because this way a single preset can deal with multiple instances of a same abstraction and still be able to distinguish which one is being referenced. See pd-l2ork K12 mode for examples of how this works (tl;dr: one abstraction hosts presets and keeps track of all other abstractions and their states)... HTH Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
Hallo IOhannes, On 08/11/2012 01:58 PM, Michael Zacherl wrote: In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not, the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)). what about dependencies within cascaded abstractions? E.g. one dynamically patched abstraction would need another one? is there a way to guarantee a sequence in order not to break connections? unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib). so it's a modified Pd-Vanilla, we have with Pd-extended, not only Pd-Vanilla plus a load of externals and abstractions? I wasn't aware of that. Now I understand all the discussions about that (not trying to open an old can of worms! ;-) instead, there is a (low-level) patch for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla). tracker? thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here) What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch. Michael. -- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] variable number of outlets/inlets /dynamic patching
From: Michael Zacherl sdiy-m...@blauwurf.info To: IOhannes m zmölnig zmoel...@iem.at Cc: pd-list list pd-list@iem.at Sent: Tuesday, August 14, 2012 9:56 AM Subject: Re: [PD] variable number of outlets/inlets /dynamic patching Hallo IOhannes, On 08/11/2012 01:58 PM, Michael Zacherl wrote: In Pd-extended it could be easier since there are more possibilities to control the init-phase of a just loaded patch. I think it's in iemlib (Iohannes could chime in) but admittedly I forgot about it, since also there was a lot of discussion wether this should go into Vanilla or not, the secrect is [initbang], which fires when the abstraction is ready (rather than [loadbang], which fires when all the patch (with all the abstractions, sub-patches and what not) is ready)). what about dependencies within cascaded abstractions? E.g. one dynamically patched abstraction would need another one? is there a way to guarantee a sequence in order not to break connections? unfortunately, i haven't found a way to make [initbang] without hacking Pd itself, so it's not part of any library (e.g. iemlib). so it's a modified Pd-Vanilla, we have with Pd-extended, not only Pd-Vanilla plus a load of externals and abstractions? I wasn't aware of that. Now I understand all the discussions about that (not trying to open an old can of worms! ;-) instead, there is a (low-level) patch for Pd somewhere in the tracker, which is applied to Pd-extended (but unfortunately not to Pd-vanilla). tracker? thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here) What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch. Even with [initbang] it's still a hack. When designing and testing the abstraction, the user must remember to always remove the dynamically created inlets/outlets before saving, and there's no way to automate that without using yet another hack (faking mouse/cut messages, for example). -Jonathan Michael. -- feed your perception: http://blauwurf.at/ http://soundcloud.com/noiseconformist ___ 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] variable number of outlets/inlets /dynamic patching
On 14.8.2012, at 19:43 , Jonathan Wilkes wrote: thus: if you want to need [initbang] (which you do if you really need variable in/outlets in abstractions), you need to either compile Pd yourself or use Pd-extended (only the core binary, no need for any externals here) What I tried, and apparently works, is to create a maximum number of inlets/outlets and delete the ones not needed at load-time. ButI consider this one a hack and certainly doesn't improve the reliability of a dymamic patch. Even with [initbang] it's still a hack. When designing and testing the abstraction, the user must remember to always remove the dynamically created inlets/outlets before saving, and there's no way to automate that without using yet another hack (faking mouse/cut messages, for example). -Jonathan admittedly I didn't look at dynamic patching for a long time. I remember that I searched for infos on best practices etc. but didn't find anything helpful back then. so curious as I am I still wonder what would be a good way to approach this. João's [jmmmp/dacm~] is nice but 'harmless' in this respect. m. -- hear the colours of noise: http://blauwurf.at http://soundcloud.com/noiseconformist ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd Vanilla on Raspberry Pi
OK... this business of having to delay pd dsp 1 is probably the same problem some others have been having with pd -nogui - I need to investigate that one. Meanwhile there's still the problem of Pd not getting real-time scheduling turned on, which must be some kind of configuration thing. Getting that fixed would probably help a lot. cheers Miller On Tue, Aug 14, 2012 at 05:14:48AM +0200, Michael Zacherl wrote: On 14.8.2012, at 01:47 , Miller Puckette wrote: Thanks for the info... some quick ideas: good to know but that didn't help. I can't tell what it is but apparently it's a timing or order of execution issue at startup in batch-mode: Delaying the ; pd dsp 1 message by 200ms helps avoiding the device busy error. Same patch loaded in the gui, no problem. :-\ According to 'top' the cpu load drops from 75% to about 70% with -nogui for a 4k-window. Just about enough to avoid glitching. But any system activity brings the sound to a halt for a short moment. So that was just an ssh-session and Pd running in batch-mode. At some point I'll go through this and see what can be done: http://puredata.info/community/pdwiki/Optimize/ BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible. Yep: the message is ; pd quit ah, of course! thanks, Michael. -- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist ___ 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
