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
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
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
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]
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 -
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
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
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
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 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,
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
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
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).
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
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
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:
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
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
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
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,
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
21 matches
Mail list logo
