Re: [PD] abstraction penalty benchmarks
On 08/09/2013 08:01 PM, Miller Puckette wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. So the problem doesn't happen with [s $0-loop]? -Jonathan cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/10/2013 10:37 AM, Jonathan Wilkes wrote: On 08/09/2013 08:01 PM, Miller Puckette wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. So the problem doesn't happen with [s $0-loop]? I mean [r $0-loop] -Jonathan -Jonathan cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
I believe it should not happen ($1-loop would expand to different symbols depending on $1). cheers M On Sat, Aug 10, 2013 at 11:23:19AM -0400, Jonathan Wilkes wrote: On 08/10/2013 10:37 AM, Jonathan Wilkes wrote: On 08/09/2013 08:01 PM, Miller Puckette wrote: Well, if ia user really wants 32K receives of the same name, (s)he can have them - but most people won't want to do that. In contrast, you can't have 32K copies of an abstraction without hitting this problem - and the business of binding patches to names is only rarely actually used. So (I'm now thinking) Pd should make it easy to defeat that useless behavior. So the problem doesn't happen with [s $0-loop]? I mean [r $0-loop] -Jonathan -Jonathan cheers M On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote: On 08/09/2013 04:31 PM, Miller Puckette wrote: Or... just limit the number of canvases that can bind themselves to a single symbol to a reasonable number (5 or so, settable by flag for back-compatibility if anyone cares). What happens to Claude's test if you a) patch Pd to stop binding pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd] inside the abstraction that's getting massively replicated? I'd hypothesize that you end up with the same or closely similar problem, no? If so then messing with the abstraction name binding risks introducing bugs or breaking some strange but interesting patches, and doesn't solve the larger problem which becomes anxiety about [s]/[r] pairs or any other nonlocal connection objects inside abstractions. -Jonathan cheers M On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote: On 09/08/13 19:42, Miller Puckette wrote: There still could be situations where an abstraction has a sub-patch (pd foo for instance) - I'm not clear as to whether those namings should be supressed as well. It seems like a tricky problem - lots of people seem to use abstractions with only one instance and might be depending on the bindings. Maybe the best fix would be to make pd_unbind() constant time (perhaps by storing bindings in a doubly-linked list instead of a singly-linked list) and be done with it, instead of hacking workarounds.. Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Benefits of using an external soundcard?
Brian: I comment between lines: El 09/08/13 09:42, Brian Fay escribió: Is there a specific type of microphone you will be using? I've seen some videos of Beardyman recently using some type of hands-free lavalier microphone. I will use my wireless VHF SHURE microphone (I know it is old). The original is a headset, but, for beatbox, I use a SM-58 connected to the same trasnmisor. It sounds different, so, the SM-58 jack has a resistor to turn the gain down and an EQ in PureData, to make it sound like the other. I don't know if I will use the headset (as Beardyman) or the SM-58. It is about comfort. This and other condenser microphones require Phantom Power, which is provided by many audio interfaces and mixers but generally not built in to an internal soundcard. It doesn't need phantom power. See how far you can get with what you have; there's no point in buying something that you don't need. But you might find that you do need one eventually. I will buy the cheap soundcard (ARS $200). I understand what you say, but it has some benefits: - I care the notebook audio-out jack. USB is more resistent for pluging and unpluging. I (this) summer, I work in a park and I do what this video shows, EVERYNIGHT: http://www.youtube.com/watch?v=oNUZULR7k18 - I have more inputs and outputs (for future features). - Maybe, I avoid noise in the line (for the moment, I don't have it... but I think it depends on the power line of the location). - Sometimes, I do record some samples... it will be usefull for that. Keep in mind that you'll need very low latency (less than 20 miliseconds) for your application. I'm not sure if this is affected by the sound card or not. All of the audio processing happens on the CPU, but maybe the buffering stages for the sound card add enough delay to add latency... could somebody with more familiarity chime in here? For now, I have 5.8ms of latency. It's very good for me. If you are saying that an external soundcard would add latency... more than the internal, so, it is not good! Thanks. On Fri, Aug 9, 2013 at 7:28 AM, Mario Mey mario...@gmail.com mailto:mario...@gmail.com wrote: El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I think you mean I should... If you're planning on recording something on just 2 channels on the built-in sound card, keep in mind that your dynamic range will be pretty bad, even if you get a good pre-amp in the middle to take the most advantage of your range. You'd much rather have an external sound card with some adjustable analog pre-amps in the box. About the soundcard I post, the Encore 7.1 ENMAB-8CM (http://www.encore-usa.com/ar/support/ENMAB-8CM)... it's really a china generic useless card... or it's good for starting? It has no analog pot. Chuck Thanks so much for your time. On Thu, Aug 8, 2013 at 3:30 PM, Mario Mey mario...@gmail.com mailto:mario...@gmail.com wrote: I'm using my integrated soundcard: 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40). I know that Pd is processing on CPU and I don't need more than 2 inputs and 2 outputs channels. So... I think that there's no need to buy an external one. Is there any benefit of using one? I know that this USB soundcard is not a very good one... but maybe it's good for my economy. What's your opinion? http://www.encore-usa.com/ar/support/ENMAB-8CM
Re: [PD] Benefits of using an external soundcard?
Charles, as I answer to Brian, I paste the same about the soundcard /I will buy the cheap soundcard (ARS $200). I understand what you say, but it has some benefits:// // //- I care the notebook audio-out jack. USB is more resistent for pluging and unpluging. I (this) summer, I work in a park and I do what this video shows, EVERYNIGHT: http://www.youtube.com/watch?v=oNUZULR7k18// //- I have more inputs and outputs (for future features).// //- Maybe, I avoid noise in the line (for the moment, I don't have it... but I think it depends on the power line of the location).// //- Sometimes, I do record some samples... it will be usefull for that.// / And, you can check BEARDYTRON_5000 here: http://www.youtube.com/watch?v=_OlHSNpYg0A and other videos there. Thanks. El 09/08/13 11:34, Charles Z Henry escribió: On Fri, Aug 9, 2013 at 6:28 AM, Mario Mey mario...@gmail.com mailto:mario...@gmail.com wrote: El 08/08/13 17:50, Charles Z Henry escribió: Hi Mario The number one reason for having an external sound card is noise isolation. The card's proximity to the power supply and motherboard are bad for EM noise. Also, a computer power supply and a good audio power supply for recording have much the same relationship--there's more noise in switching electronics. Next, there's the size constraints. You'd have a hard time adding all the connectors for a large number of channels on a card which plugs in to your PCI(e) slots. It's ok, I have a notebook: 1 plug out, 1 plug in. Third: there's not as great a need for bandwidth for audio as there is with video. Video cards need all that PCI(e) bandwidth. Audio doesn't. It's a relatively small amount of data. Of course--I think USB and firewire really don't have enough bandwidth for good scalability, but that's another discussion. But... what are you doing with it? You have different requirements for recording and for live sound. Live sound: just do it up. No one will likely notice. Live sound is my purpose. Mic-in looping-station and multieffects system (following the steps of Beardyman and his Beardytron_5000). But, sorry about not understanding your expresion (english is not my native language) What do you mean with just do it up, no one will likely notice? Should I buy it or no one will notice the difference? I think you mean I should... Just use the onboard sound. Live performance or installations can be much more tolerant of noise. You may have to tune your patches for the hardware, but don't give it too much thought and just do it up (a recommendation). I'm not familiar with Beardyman/tron_5000. That sounds cool. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] portaudio callback problem [WAS:Re: PA_Terminate]
Hi Patrice - I actually don't have any working ASIO devices which makes it hard for me to figure out what's wrong here. I'll make another attemot to get something installed in the next week or so. Meanwhile, am I reading this right that you get different results depending on whether you put the -asio flag before or after the -audioindev 13 -audiooutdev 12 ? I don't know why that would happen. cheers Miller On Sat, Jul 27, 2013 at 03:46:49AM +0200, Colet Patrice wrote: Le 27/07/2013 00:39, Colet Patrice a écrit : Hello, I'm trying to find out why portaudio doesn't work with my windows machine. pd doesn't stuck anymore if I put Pa_Terminate() at the end of function static void pa_init(void) in s_audio_pa.c I don't understand why Pa_Terminate() is not used anymore, it's under comments in function int pa_open_audio() because by reading http://portaudio.com/docs/v19-doxydocs/initializing_portaudio.html, I see that this function must be used. It doesn't matter anymore because I've partly resolved the problem, and it partly comes from portaudio... If pa_process.c has been modified like explained in following link: http://music.columbia.edu/pipermail/portaudio/2012-December/014649.html audioindev audiooutdev can be forced before declaring asio like this: pd -audioindev 13 -audiooutdev 12 -asio Then It's possible to know which device to use with this command: pd -audioindev 0 -audiooutdev 0 -asio -listdev I hope someone can rewrite PaError pa_open_callback(...) in s_audio_pa.c because all those problems mainly comes from this function, and asio will certainly work better for everyone. My guess would be about making sure that p_instreamparams and p_outstreamparams aren't NULL before starting pa_stream. cheers, PatCo ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
