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 Kel
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, n
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 wrote:
> Check Ohm's law.
>
> V=IR, so the resistor you choose is the voltage you provide to the LED
> divided by the curr
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
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 au
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.ne
On Wed, Aug 7, 2013 at 2:57 AM, Roman Haefeli 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 diffe
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
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). M
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
On Wed, Aug 7, 2013 at 12:05 AM, Epic Jefferson 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
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,
metr
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.
Thank
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
> Subject: Re: [PD] routeOSC - dynamic routing?
> Date: August 7, 2013 7:16:13 AM EDT
> To: pd-list@iem.at
>
>
> On Wed, 2013-08-
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: rang
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
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
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
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
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 su
20 matches
Mail list logo