Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. those were the times. fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui object arguments
On 08/07/13 07:49, Dan Wilcox wrote: Do any of the pd gui / iem gui objects take creation args? Forgive me if I missed this in the help patches. all of them do, as this is the way how they keep their properties when loading a patch. on the downside, most of these arguments are not really meant for humans to parse/write. and afair, they don't support short lists of arguments (so you have to specify all arguments, or a rather longish subset) fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC - dynamic routing?
On Wed, 2013-08-07 at 02:15 -0400, pured...@11h11.com wrote: hi all, i have more than 50 OSC messages to [routeOSC], i would like to avoid having to cut and paste click and drag. what are my options here? [routeOSC /knob1 /knob2 ...] | | [s $0-knob1] [s $0-knob2] thanks Instead of routing with [routeOSC], you could use the last address field directly as the send address: [/knobs/knob1 23( | [routeOSC /knobs/ | [list] | [; $1 $2( As an alternative to the ;-messagebox with hard-coded number of elements, you could employ a settable [send] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
hi, great news you're not stuck ! try to find logic-level P-channel mosfets, preferably TTL ones. SPP15P10PL at digikey looks like a good match. Enjoy, Charles ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC - dynamic routing?
Le 07/08/2013 08:15, pured...@11h11.com a écrit : hi all, i have more than 50 OSC messages to [routeOSC], i would like to avoid having to cut and paste click and drag. what are my options here? [routeOSC /knob1 /knob2 ...] | | [s $0-knob1] [s $0-knob2] thanks someting like this, and no need for routeOSC [dumpOSC]-[set $1 $2, bang(--[ ( [r /knob1] ... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui object arguments
Hah ok, that's what I figured but didn't try. After writing patch file parsing for PdParty, I agree that they are not human readable. It would be nice if there was a short list as you say for the most obvious options. On Aug 7, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote: From: IOhannes m zmölnig zmoel...@iem.at Subject: Re: [PD] gui object arguments Date: August 7, 2013 2:42:33 AM EDT To: pd-list@iem.at On 08/07/13 07:49, Dan Wilcox wrote: Do any of the pd gui / iem gui objects take creation args? Forgive me if I missed this in the help patches. all of them do, as this is the way how they keep their properties when loading a patch. on the downside, most of these arguments are not really meant for humans to parse/write. and afair, they don't support short lists of arguments (so you have to specify all arguments, or a rather longish subset) fgmasdr IOhannes Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui object arguments
In looking at g_hslider.c, I imagine something like the following in
hslider_new():
// 2 args: range
else if((argc == 2) || IS_A_FLOAT(argv, 0) IS_A_FLOAT(argv, 1)) {
min = (double)atom_getfloatarg(0, argc, argv);
max = (double)atom_getfloatarg(1, argc, argv);
}
// 4 args: range size
else if((argc == 4) || IS_A_FLOAT(argv, 0) IS_A_FLOAT(argv, 1)
IS_A_FLOAT(argv, 2) IS_A_FLOAT(argv, 3))
{
w = (int)atom_getintarg(0, argc, argv);
h = (int)atom_getintarg(1, argc, argv);
min = (double)atom_getfloatarg(2, argc, argv);
max = (double)atom_getfloatarg(3, argc, argv);
}
And an equivalent for the other gui objects.
On Aug 7, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote:
From: IOhannes m zmölnig zmoel...@iem.at
Subject: Re: [PD] gui object arguments
Date: August 7, 2013 2:42:33 AM EDT
To: pd-list@iem.at
On 08/07/13 07:49, Dan Wilcox wrote:
Do any of the pd gui / iem gui objects take creation args? Forgive me if
I missed this in the help patches.
all of them do, as this is the way how they keep their properties when
loading a patch.
on the downside, most of these arguments are not really meant for humans
to parse/write.
and afair, they don't support short lists of arguments (so you have to
specify all arguments, or a rather longish subset)
fgmasdr
IOhannes
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC - dynamic routing?
Dunno if this would be of any use (attached) but I've been making use of [entry] to keep an eye on incoming OSC streams so instead of hundreds of messages whizzing by this allows to just see when the data changes. Shouldn't be too difficult to parse and dump the various OSC addresses either. Thanks to Mike MB for helping figure the dataflow. Cheers, Julian On 7 August 2013 14:55, Dan Wilcox danomat...@gmail.com wrote: Ah, that's much simpler than what I was thinking. How do you always do it Roman? :D On Aug 7, 2013, at 9:44 AM, pd-list-requ...@iem.at wrote: *From: *Roman Haefeli reduz...@gmail.com *Subject: **Re: [PD] routeOSC - dynamic routing?* *Date: *August 7, 2013 7:16:13 AM EDT *To: *pd-list@iem.at On Wed, 2013-08-07 at 02:15 -0400, pured...@11h11.com wrote: hi all, i have more than 50 OSC messages to [routeOSC], i would like to avoid having to cut and paste click and drag. what are my options here? [routeOSC /knob1 /knob2 ...] | | [s $0-knob1] [s $0-knob2] thanks Instead of routing with [routeOSC], you could use the last address field directly as the send address: [/knobs/knob1 23( | [routeOSC /knobs/ | [list] | [; $1 $2( As an alternative to the ;-messagebox with hard-coded number of elements, you could employ a settable [send] Roman Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list OSC_entry.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables (link http://www.instructables.com/id/Controlling-solenoids-with-arduino/)) and it uses a single pin to control the pwm signal. The pwm shield (link http://www.practicalmaker.com/products/arduino-shields/pwm-shield-assembled ) is based on the tlc5940 which requires each pin to have it's own ground instead of a common ground across all drivers. This is a problem because all of the information i've found suggest that the signal from the pin controls the gate (transistor - TIP102). But i think, in the case of the tlc5940, the 5v supply is constant and the ground is being controlled, that's why it works perfectly for LED's but seems to be ill suited for this circuit. Any suggestions on how to modify the instructables circuit for use with the shields? or would the circuit have to completely change? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit 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] How to reduce CPU use on unused subpatches-abstracts?
Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change #define HASHSIZE 1024 to #define HASHSIZE 65536 or so, recompile and see if that makes it run faster. (Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?) cheers Miller On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote: Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Oh... *compile*... I'm afraid of that word. Once (during some days), I tried to compile Pd... but with no good results. I will try to download the source, look for a easy-to-compile tutorial... but, if it takes me so much time, I think I'll go on with the current version of PdExt (0.43.4). Maybe I will try it later... or later... or even more later. To profile Pd, is there an option in my version, or I have to change code, like #define PROFILE 1? Cheers. El 07/08/13 16:53, Miller Puckette escribió: Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change #define HASHSIZE 1024 to #define HASHSIZE 65536 or so, recompile and see if that makes it run faster. (Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?) cheers Miller On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote: Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Oops, sorry - I think I'm leading you astray - it might take a long time to figure out how to patch sources adn recompile Pd if you aren't already habituated to compiling software. Anyway, I don't really know that it's gensym() that's taking the 6% of your processor - that's just a guess. So I'm not sure what to try next... Miller On Wed, Aug 07, 2013 at 05:23:16PM -0300, Mario Mey wrote: Oh... *compile*... I'm afraid of that word. Once (during some days), I tried to compile Pd... but with no good results. I will try to download the source, look for a easy-to-compile tutorial... but, if it takes me so much time, I think I'll go on with the current version of PdExt (0.43.4). Maybe I will try it later... or later... or even more later. To profile Pd, is there an option in my version, or I have to change code, like #define PROFILE 1? Cheers. El 07/08/13 16:53, Miller Puckette escribió: Here's an idea ... perhaps your patch is generating hundreds of thousands of symbols to instantiate all the abstractions, and this sould be making gensym() run slowly. To test this possibility easily you could change #define HASHSIZE 1024 to #define HASHSIZE 65536 or so, recompile and see if that makes it run faster. (Of course, I don't know why gensym() would be getting called periodically when Pd is idling; perhaps you could find that out by profiling Pd?) cheers Miller On Wed, Aug 07, 2013 at 04:32:30PM -0300, Mario Mey wrote: Thanks all for responding. After doing some tests, with suggestion from mail-list and from (Maelstorm), I want to show you the current structure of the complete patch (the same I wrote in forum): /Main patch (meh_system.pd)// //• OSC messaging (for the tablet), input and output (EQ), BPM, metronome, Beats-to-rec, mode selector, etc.// //• FXs Console x2 (meh_console.pd)// //- - FXs group selector, X-Y pad, Hold button, some signal and message redirection, etc. (subpatches)// //- - FXs groups x8 subpatches.// //- - - FXs abstracts x100 (fx-*.pd) ***// //• Sample Bank X8 (meh_bank.pd)// //- - Control subpatch [pd toggle-color-seteos]// //- - Sample - Resample subpatch [pd rec-sample-resample] ***// //- - Looping subpatch [pd rec-looping] ***// //- - Overdub subpatch [pd overdub] ***// //- - Playing subpatch [pd play]// // /The ones that have ***, have [switch~] inside. Using throw~/catch~ and s~/r~, the audio signals (right/left, sample/resample) get inside and outside all that subpatches-abstracts. After adding switch~ inside them, *I got these RESULTS*: /•/ Ready-to-use, 2 FXs on: *26%* (there are 2 FXs always on, although they are muted) /• /7 Banks playing, 1 Overdubbing, 2 FXs on: *32%* /• /DSP off: *6%* As you can see, from 47%, I achieve 20% less than before. I think it is very good! But, with DSP off, I have 6% and there's no message processing. Maelstorm told me that it is too much for doing nothing... and, we think that it is because of having all that abstracts there. If I delete them, I have 1-2%. The FX Console abstract (main patch has 2 of them) has all the FXs inside (100 items). Each FX has 4 to 8 abstracts inside (most of them are DIY2 effects, by Hardoff, but it also has a Panel abstract and some others). So... 2 * 100 * 6 = 1200 abstracs, more or less. Even if they are swithched off... THEY ARE THERE. Maybe this increase the CPU to 6%? I repeat the WIP thread, where MEH-SYSTEM can be downloaded and tested: http://puredata.hurleur.com/viewtopic.php?pid=37430 (it uses externals from PdExt and the zip includes ipoke2~.pd_linux for 64bits (my version of ipoke~, by Katja), but it's only for overdubbing) Thanks again. El 07/08/13 04:57, Roman Haefeli escribió: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli reduz...@gmail.com wrote: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman I don't know why this is so... When you add a [switch~] object, it adds a prologue and epilogue around the perform routines from each object in the subpatch. The runtime behavior is just like [block~], except when the patch is switched off, the switch prologue returns a pointer to the epilogue, instead of the next item in the dsp chain (don't quote me--I may need to read some code to find exact behavior, but that's the gist of it). To me, this is pretty minimal and reasonable. Maybe there's an unintended consequence like cache misses when skipping over part of the dsp chain. Chuck ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gui object arguments
On 08/07/2013 01:49 AM, Dan Wilcox wrote:
Do any of the pd gui / iem gui objects take creation args? Forgive me
if I missed this in the help patches.
For Pd-extended and Pd-l2ork:
Should be in a subpatch for the relevant object class, named
${iemgui}_creation_arguments:
http://sourceforge.net/p/pure-data/svn/17190/tree/trunk/doc/pddp/vslider-help.pd
Let me know if I missed any.
-Jonathan
My thought is that it would be nice to be able to create and set a
slider's range like this [hsl 0 1] or set the number of radio buttons
like [hradio 2] ...
Dan Wilcox
@danomatika
danomatika.com http://danomatika.com
robotcowboy.com http://robotcowboy.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Whoa! I wonder - this was a libpd app I made, and it definitely made a difference putting all the DSP on one layer, but it was complex and I may have missed a trick here. It runs on an iPhone, and I wonder if there is a difference in how that works. resolving abstractions and subpatches with audio dropped the CPU load on an iPhone 4 from 132% to 71%. Unless teh people writing the GUI fixed a big bad bug without telling me? I didn't seem like that at the time...if it wasn't the case I could have saved myself some pain. Cheers, Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Charles Z Henry czhe...@gmail.com To: Roman Haefeli reduz...@gmail.com Cc: pd-list pd-list@iem.at Sent: Wednesday, 7 August 2013, 21:48 Subject: Re: [PD] How to reduce CPU use on unused subpatches-abstracts? On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli reduz...@gmail.com wrote: On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman I don't know why this is so... When you add a [switch~] object, it adds a prologue and epilogue around the perform routines from each object in the subpatch. The runtime behavior is just like [block~], except when the patch is switched off, the switch prologue returns a pointer to the epilogue, instead of the next item in the dsp chain (don't quote me--I may need to read some code to find exact behavior, but that's the gist of it). To me, this is pretty minimal and reasonable. Maybe there's an unintended consequence like cache misses when skipping over part of the dsp chain. Chuck ___ 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] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
Check Ohm's law. V=IR, so the resistor you choose is the voltage you provide to the LED divided by the current it draws. e.g. if the LED draws 20mA and you power it from 5V, then the resistor you need is 5/0.02 = 250 ohms in series with the LED. This current is drawn from the positive voltage supply through the resistor and then the LED, and then the transistor. This is a fairly good tutorial: http://www.ehobbycorner.com/pages/tut_transistors.html Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Charles Z Henry czhe...@gmail.com To: Epic Jefferson jeffreyconcepc...@gmail.com Cc: pd-list pd-list@iem.at Sent: Wednesday, 7 August 2013, 20:41 Subject: Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables (linkhttp://www.instructables.com/id/Controlling-solenoids-with-arduino/)) and it uses a single pin to control the pwm signal. The pwm shield (linkhttp://www.practicalmaker.com/products/arduino-shields/pwm-shield-assembled) is based on the tlc5940 which requires each pin to have it's own ground instead of a common ground across all drivers. This is a problem because all of the information i've found suggest that the signal from the pin controls the gate (transistor - TIP102). But i think, in the case of the tlc5940, the 5v supply is constant and the ground is being controlled, that's why it works perfectly for LED's but seems to be ill suited for this circuit. Any suggestions on how to modify the instructables circuit for use with the shields? or would the circuit have to completely change? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit Org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
note that you have to subtract the voltage drop over the LED, hence it's R = (Vsupply - Vled)/ Iled, e.g. (5-2)/0.02 = 150 Ohm /Mikael On 8 Aug 2013, at 00:19, Ed Kelly morph_2...@yahoo.co.uk wrote: Check Ohm's law. V=IR, so the resistor you choose is the voltage you provide to the LED divided by the current it draws. e.g. if the LED draws 20mA and you power it from 5V, then the resistor you need is 5/0.02 = 250 ohms in series with the LED. This current is drawn from the positive voltage supply through the resistor and then the LED, and then the transistor. This is a fairly good tutorial: http://www.ehobbycorner.com/pages/tut_transistors.html Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Charles Z Henry czhe...@gmail.com To: Epic Jefferson jeffreyconcepc...@gmail.com Cc: pd-list pd-list@iem.at Sent: Wednesday, 7 August 2013, 20:41 Subject: Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables (linkhttp://www.instructables.com/id/Controlling-solenoids-with-arduino/)) and it uses a single pin to control the pwm signal. The pwm shield (linkhttp://www.practicalmaker.com/products/arduino-shields/pwm-shield-assembled) is based on the tlc5940 which requires each pin to have it's own ground instead of a common ground across all drivers. This is a problem because all of the information i've found suggest that the signal from the pin controls the gate (transistor - TIP102). But i think, in the case of the tlc5940, the 5v supply is constant and the ground is being controlled, that's why it works perfectly for LED's but seems to be ill suited for this circuit. Any suggestions on how to modify the instructables circuit for use with the shields? or would the circuit have to completely change? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit Org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
Oh, thanks. That was dumb I didn't remember that! Is it really 2 volts drop for an LED? I should know this stuff... Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Mikael Fernström mikael.fernst...@ul.ie To: Ed Kelly morph_2...@yahoo.co.uk Cc: Charles Z Henry czhe...@gmail.com; Epic Jefferson jeffreyconcepc...@gmail.com; pd-list pd-list@iem.at Sent: Thursday, 8 August 2013, 0:26 Subject: Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue note that you have to subtract the voltage drop over the LED, hence it's R = (Vsupply - Vled)/ Iled, e.g. (5-2)/0.02 = 150 Ohm /Mikael On 8 Aug 2013, at 00:19, Ed Kelly morph_2...@yahoo.co.uk wrote: Check Ohm's law. V=IR, so the resistor you choose is the voltage you provide to the LED divided by the current it draws. e.g. if the LED draws 20mA and you power it from 5V, then the resistor you need is 5/0.02 = 250 ohms in series with the LED. This current is drawn from the positive voltage supply through the resistor and then the LED, and then the transistor. This is a fairly good tutorial: http://www.ehobbycorner.com/pages/tut_transistors.html Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Charles Z Henry czhe...@gmail.com To: Epic Jefferson jeffreyconcepc...@gmail.com Cc: pd-list pd-list@iem.at Sent: Wednesday, 7 August 2013, 20:41 Subject: Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables (linkhttp://www.instructables.com/id/Controlling-solenoids-with-arduino/)) and it uses a single pin to control the pwm signal. The pwm shield (linkhttp://www.practicalmaker.com/products/arduino-shields/pwm-shield-assembled) is based on the tlc5940 which requires each pin to have it's own ground instead of a common ground across all drivers. This is a problem because all of the information i've found suggest that the signal from the pin controls the gate (transistor - TIP102). But i think, in the case of the tlc5940, the 5v supply is constant and the ground is being controlled, that's why it works perfectly for LED's but seems to be ill suited for this circuit. Any suggestions on how to modify the instructables circuit for use with the shields? or would the circuit have to completely change? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit 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] electro-mechanical piano (player piano) - Arduino, Solenoid Issue
It depends on the colour and the LED technology. The energy of red light is about 1.5eV and blue is 3eV. Add to that internal resistance of the device. An ordinary diode (not a LED) emits infrared around .6eV, which is the voltage drop of a silicon junction. Martin On 2013-08-07 20:02, Ed Kelly wrote: Oh, thanks. That was dumb I didn't remember that! Is it really 2 volts drop for an LED? I should know this stuff... Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ *From:* Mikael Fernström mikael.fernst...@ul.ie *To:* Ed Kelly morph_2...@yahoo.co.uk *Cc:* Charles Z Henry czhe...@gmail.com; Epic Jefferson jeffreyconcepc...@gmail.com; pd-list pd-list@iem.at *Sent:* Thursday, 8 August 2013, 0:26 *Subject:* Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue note that you have to subtract the voltage drop over the LED, hence it's R = (Vsupply - Vled)/ Iled, e.g. (5-2)/0.02 = 150 Ohm /Mikael On 8 Aug 2013, at 00:19, Ed Kelly morph_2...@yahoo.co.uk mailto:morph_2...@yahoo.co.uk wrote: Check Ohm's law. V=IR, so the resistor you choose is the voltage you provide to the LED divided by the current it draws. e.g. if the LED draws 20mA and you power it from 5V, then the resistor you need is 5/0.02 = 250 ohms in series with the LED. This current is drawn from the positive voltage supply through the resistor and then the LED, and then the transistor. This is a fairly good tutorial: http://www.ehobbycorner.com/pages/tut_transistors.html Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ *From:* Charles Z Henry czhe...@gmail.com mailto:czhe...@gmail.com *To:* Epic Jefferson jeffreyconcepc...@gmail.com mailto:jeffreyconcepc...@gmail.com *Cc:* pd-list pd-list@iem.at mailto:pd-list@iem.at *Sent:* Wednesday, 7 August 2013, 20:41 *Subject:* Re: [PD] electro-mechanical piano (player piano) - Arduino, Solenoid Issue On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson jeffreyconcepc...@gmail.com mailto:jeffreyconcepc...@gmail.com wrote: Hey Charles, it seems like this might work. i got some pnp transistors and built the circuit from julianvogels site. The only problem is that the LED on the test circuit barely lit up. I think it's because the transistors are not for 20mA, none were available. i'll check another electronics store to see if i find some. I think you just need smaller resistors. Every transistor in a 3-pin package I've ever seen could run 20mA or much greater. Swapping the transistors will have no effect on the amount of current. Chuck There are two ways to solve your problem: The proper one is to use PNP transistors or P-channel mosfets (remember I already told you about that ? :)) See this document, you can find the wiring at the end: http://julianvogels.de/wp-content/uploads/2013/06/stromkreis_transistorschaltung_final-1024x627.png http://julianvogels.de/extending-pwm-output-pins-with-a-texas-instruments-tlc5940-led-driver/ The good enough one is to put a pull-up resistor (10k works) on every NPN transistor base, and use the TLC as a pull down. In this case, the on-time on the TLC corresponds to the off-time on the solenoid. Also when the arduino reboots and every time the BLANK is issued, every solenoid will act for a very short time. This can be a big problem in your project. I did this for a 96 channels motor+led strip system, and I regret not using PNPs instead. Enjoy, -- Charles Epic Jefferson wrote: Hey guys, updating on this project. I got the pwm shields and i've hit a wall. The driver circuit I'm using to control the solenoids via arduino is this one from instructables
