Re: [PD] comport & Arduino

[rolfm]

(probably, to formulate the right clear question, would be answering it.)

IOhannes wrote:


the serial port of the Arduino has a max. data rate of 115200 bits/sec.
[comport] input & output is in bytes of 8 bits.
over the line 1 stopbit is added.
that comes down to almost 13 bytes/msec.

in Pd [comport] can be fed 'instantaneously' with a bunch of bytes.
am i right in my understanding that [comport] takes care of the  
handling of these bytes according with the speed of the connection,

and on the Pd side all should be well, as long there is no stack overflow.


@Alexandros:

13 bytes/msec is not a lot.

the patch in the Arduino has a 'duty-cycle' of 20 msec to feed the motors.
in this time 4 AnalogReads  are sent to Pd, and from Pd are sent the  
changed values for the motors (up to 8) and some digital pins.


i'm afraid that extending the communication with sending back an  
acknowledge, waiting for the acknowledge and eventualy resending the  
missed message, is just not possible with this bitrate.


rolf

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] creating a pseudo random list

[Pagano, Patrick]

i want to create a sequence of (8), (16), (32)numbers between -24 and 24 for 
octaves/duples

without commas for use in a pd sequence.


Can someone suggest a object that would help me out?


PP


Patrick Pagano B.S, M.F.A
Audio and Projection Design Faculty
Digital Worlds Institute
University of Florida, USA
(352)294-2020
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] creating a pseudo random list

[IOhannes m zmölnig]

On 09/04/2015 10:55 PM, Pagano, Patrick wrote:
> i want to create a sequence of (8), (16), (32)numbers between -24 and 24 for 
> octaves/duples
> 
> without commas for use in a pd sequence.
> 
> 
> Can someone suggest a object that would help me out?
> 

[random] + [list append]?


fdsmr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] creating a pseudo random list

[Jack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Patrick,

There is an exemple called [list-random] in the "list-abs" using
[random] and [list prepend].
There is a lot of abstractions in "list-abs" for operations on lists.
https://puredata.info/downloads/list-abs
++

Jack



Le 05/09/2015 00:06, IOhannes m zmölnig a écrit :
> On 09/04/2015 10:55 PM, Pagano, Patrick wrote:
>> i want to create a sequence of (8), (16), (32)numbers between -24
>> and 24 for octaves/duples
>> 
>> without commas for use in a pd sequence.
>> 
>> 
>> Can someone suggest a object that would help me out?
>> 
> 
> [random] + [list append]?
> 
> 
> fdsmr IOhannes
> 
> 
> 
> ___ 
> Pd-list@lists.iem.at mailing list UNSUBSCRIBE and
> account-management -> http://lists.puredata.info/listinfo/pd-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV6iATAAoJEOuluecjw8GUlO8H/2S/TefKC+0zUPW1PH1KOFSk
DXLoyoodpilPpK1vY78gnDmHAnVMYZ76dGmDlamfnw4gEOxm7R+Wc2f5BiOaVvtH
PFfiJSjH8ynkNnkwZZiexPB9fQsZwWhQpt1iNtDxdJO28/vEzSa1ehWKPII17SxY
jqfxPqdM+rWzVDtqoxOyq9JxAp5xqo88YwNTGBk8txAnOLaJeuWK53v0Bjf/aUVP
qsIv7vj5e5HVM2qVSwhyLN+EdIiNa+EhnmvyJ8z/lUsOwFTYblksmtu0MHwUZJen
5Crnpf5z7z7mW7TRPQMHpKSeOawb/dyWUlleYaHuGI3Kph4CYaAWdcrxJNUPfh4=
=3K+h
-END PGP SIGNATURE-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] unexpected [array max] and [array min] behavior

[Matt Barber]

Thanks.

I meant to say that there was the same problem in [array min], but you
probably caught it in your fix.

Best,

Matt

On Fri, Sep 4, 2015 at 7:19 PM, Miller Puckette  wrote:

> Yep... thanks.  Fixed in git - may take some time for me to get out a new
> compiled version (other stuff to fix too :)
>
> M
>
>
> On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote:
> > Hi list,
> >
> > I've been playing around with the new(ish) [array] object suite in
> vanilla
> > 0.46.6. Forgive me if this is already a known issue, but it looks like
> the
> > min and max arguments aren't working properly.
> >
> > The second inlet (setting the number of points to search) works as
> > expected. The first inlet doesn't update: it seems to be set to 0 no
> matter
> > what (although the index outlet is updated, but not as expected).
> >
> > I think I see the problem in x_array.c
> >
> > The max object is defined line 723:
> >
> > typedef struct _array_max
> > {
> > t_array_rangeop x_rangeop;
> > t_outlet *x_out1;   /* value */
> > t_outlet *x_out2;   /* index */
> > int x_onset;/* search onset */
> > } t_array_max;
> >
> >
> > And the bang and float methods starting 740:
> >
> > static void array_max_bang(t_array_max *x)
> > {
> > char *itemp, *firstitem;
> > int stride, nitem, i, besti;
> > t_float bestf;
> > if (!array_rangeop_getrange(>x_rangeop, , ,
> ))
> > return;
> > for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
> > i < nitem; i++, itemp += stride)
> > if (*(t_float *)itemp > bestf)
> > bestf = *(t_float *)itemp, besti = i;
> > outlet_float(x->x_out2, besti+x->x_onset);
> > outlet_float(x->x_out1, bestf);
> > }
> >
> > static void array_max_float(t_array_max *x, t_floatarg f)
> > {
> > x->x_onset = f;
> > array_max_bang(x);
> > }
> >
> >
> > In the float method it looks like the onset is never actually assigned in
> > the x_rangeop member of the t_array_max struct, so array_rangeop_getrange
> > can't set the firstitem pointer to anything but its init value.
> >
> >
> > Thanks,
> >
> > Matt
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] unexpected [array max] and [array min] behavior

[Miller Puckette]

Yep :)

M

On Fri, Sep 04, 2015 at 07:46:30PM -0400, Matt Barber wrote:
> Thanks.
> 
> I meant to say that there was the same problem in [array min], but you
> probably caught it in your fix.
> 
> Best,
> 
> Matt
> 
> On Fri, Sep 4, 2015 at 7:19 PM, Miller Puckette  wrote:
> 
> > Yep... thanks.  Fixed in git - may take some time for me to get out a new
> > compiled version (other stuff to fix too :)
> >
> > M
> >
> >
> > On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote:
> > > Hi list,
> > >
> > > I've been playing around with the new(ish) [array] object suite in
> > vanilla
> > > 0.46.6. Forgive me if this is already a known issue, but it looks like
> > the
> > > min and max arguments aren't working properly.
> > >
> > > The second inlet (setting the number of points to search) works as
> > > expected. The first inlet doesn't update: it seems to be set to 0 no
> > matter
> > > what (although the index outlet is updated, but not as expected).
> > >
> > > I think I see the problem in x_array.c
> > >
> > > The max object is defined line 723:
> > >
> > > typedef struct _array_max
> > > {
> > > t_array_rangeop x_rangeop;
> > > t_outlet *x_out1;   /* value */
> > > t_outlet *x_out2;   /* index */
> > > int x_onset;/* search onset */
> > > } t_array_max;
> > >
> > >
> > > And the bang and float methods starting 740:
> > >
> > > static void array_max_bang(t_array_max *x)
> > > {
> > > char *itemp, *firstitem;
> > > int stride, nitem, i, besti;
> > > t_float bestf;
> > > if (!array_rangeop_getrange(>x_rangeop, , ,
> > ))
> > > return;
> > > for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
> > > i < nitem; i++, itemp += stride)
> > > if (*(t_float *)itemp > bestf)
> > > bestf = *(t_float *)itemp, besti = i;
> > > outlet_float(x->x_out2, besti+x->x_onset);
> > > outlet_float(x->x_out1, bestf);
> > > }
> > >
> > > static void array_max_float(t_array_max *x, t_floatarg f)
> > > {
> > > x->x_onset = f;
> > > array_max_bang(x);
> > > }
> > >
> > >
> > > In the float method it looks like the onset is never actually assigned in
> > > the x_rangeop member of the t_array_max struct, so array_rangeop_getrange
> > > can't set the firstitem pointer to anything but its init value.
> > >
> > >
> > > Thanks,
> > >
> > > Matt
> >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [declare -stdpath] has no effect on Windows

[Miller Puckette]

Interesting... I can't get -stdpath to work either on wine or in
linux.

But I noticed that -stdpath cecks if each directory exists before adding
it... therefore perhaps it found 'zexy' and didn't find 'osc' - in that case
it wouldn't print anything out aboutosc - it just silently ignores the
non-existent directories.

cheers
Miller

On Wed, Sep 02, 2015 at 12:00:32PM +0200, Roman Haefeli wrote:
> Hi all
> 
> I hoped to be able to dig into it myself, but I can't figure out why it
> is behaving different on Windows compared to Linux.
> 
> [declare -stdpath osc] has no effect on Windows. I have 'osc' installed
> in \extra\osc and when I create [routeOSC /bla], the Pd output
> looks like this:
> 
> tried Z:/home/roman/routeOSC.m_i386 and failed
> tried C:/Program Files/Common Files/Pd/routeOSC.m_i386 and failed
> tried C:/users/roman/Application Data/Pd/routeOSC.m_i386 and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.m_i386 and failed
> tried Z:/home/roman/routeOSC.dll and failed
> tried C:/Program Files/Common Files/Pd/routeOSC.dll and failed
> tried C:/users/roman/Application Data/Pd/routeOSC.dll and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.dll and failed
> tried Z:/home/roman/routeOSC/routeOSC.m_i386 and failed
> tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.m_i386 and failed
> tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.m_i386 and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.m_i386 and failed
> tried Z:/home/roman/routeOSC/routeOSC.dll and failed
> tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.dll and failed
> tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.dll and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.dll and failed
> tried Z:/home/roman/routeOSC.pd and failed
> tried C:/Program Files/Common Files/Pd/routeOSC.pd and failed
> tried C:/users/roman/Application Data/Pd/routeOSC.pd and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.pd and failed
> tried Z:/home/roman/routeOSC.pat and failed
> tried C:/Program Files/Common Files/Pd/routeOSC.pat and failed
> tried C:/users/roman/Application Data/Pd/routeOSC.pat and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC.pat and failed
> tried Z:/home/roman/routeOSC/routeOSC.pd and failed
> tried C:/Program Files/Common Files/Pd/routeOSC/routeOSC.pd and failed
> tried C:/users/roman/Application Data/Pd/routeOSC/routeOSC.pd and failed
> tried Z:/home/roman/pd-src/w32/pd/extra/routeOSC/routeOSC.pd and failed
>  routeOSC /bla
> error: ... couldn't create
> 
> (The output is actually from Wine, but it really behaves the same on Windows)
> 
> There is no mention of 'osc' whatsoever.
> 
> On the other hand, [declare -stdlib zexy] works the same on Linux and on
> Windows.
> 
> [declare -stdpath] used to work on Windows in older version of Pd, but I
> can't tell exactly since when it isn't working anymore.
> 
> Roman
> 
> 
> 
> 
> 



> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] unexpected [array max] and [array min] behavior

[Matt Barber]

Hi list,

I've been playing around with the new(ish) [array] object suite in vanilla
0.46.6. Forgive me if this is already a known issue, but it looks like the
min and max arguments aren't working properly.

The second inlet (setting the number of points to search) works as
expected. The first inlet doesn't update: it seems to be set to 0 no matter
what (although the index outlet is updated, but not as expected).

I think I see the problem in x_array.c

The max object is defined line 723:

typedef struct _array_max
{
t_array_rangeop x_rangeop;
t_outlet *x_out1;   /* value */
t_outlet *x_out2;   /* index */
int x_onset;/* search onset */
} t_array_max;


And the bang and float methods starting 740:

static void array_max_bang(t_array_max *x)
{
char *itemp, *firstitem;
int stride, nitem, i, besti;
t_float bestf;
if (!array_rangeop_getrange(>x_rangeop, , , ))
return;
for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
i < nitem; i++, itemp += stride)
if (*(t_float *)itemp > bestf)
bestf = *(t_float *)itemp, besti = i;
outlet_float(x->x_out2, besti+x->x_onset);
outlet_float(x->x_out1, bestf);
}

static void array_max_float(t_array_max *x, t_floatarg f)
{
x->x_onset = f;
array_max_bang(x);
}


In the float method it looks like the onset is never actually assigned in
the x_rangeop member of the t_array_max struct, so array_rangeop_getrange
can't set the firstitem pointer to anything but its init value.


Thanks,

Matt
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] unexpected [array max] and [array min] behavior

[Miller Puckette]

Yep... thanks.  Fixed in git - may take some time for me to get out a new
compiled version (other stuff to fix too :)

M


On Fri, Sep 04, 2015 at 05:51:15PM -0400, Matt Barber wrote:
> Hi list,
> 
> I've been playing around with the new(ish) [array] object suite in vanilla
> 0.46.6. Forgive me if this is already a known issue, but it looks like the
> min and max arguments aren't working properly.
> 
> The second inlet (setting the number of points to search) works as
> expected. The first inlet doesn't update: it seems to be set to 0 no matter
> what (although the index outlet is updated, but not as expected).
> 
> I think I see the problem in x_array.c
> 
> The max object is defined line 723:
> 
> typedef struct _array_max
> {
> t_array_rangeop x_rangeop;
> t_outlet *x_out1;   /* value */
> t_outlet *x_out2;   /* index */
> int x_onset;/* search onset */
> } t_array_max;
> 
> 
> And the bang and float methods starting 740:
> 
> static void array_max_bang(t_array_max *x)
> {
> char *itemp, *firstitem;
> int stride, nitem, i, besti;
> t_float bestf;
> if (!array_rangeop_getrange(>x_rangeop, , , ))
> return;
> for (i = 0, besti = 0, bestf= -1e30, itemp = firstitem;
> i < nitem; i++, itemp += stride)
> if (*(t_float *)itemp > bestf)
> bestf = *(t_float *)itemp, besti = i;
> outlet_float(x->x_out2, besti+x->x_onset);
> outlet_float(x->x_out1, bestf);
> }
> 
> static void array_max_float(t_array_max *x, t_floatarg f)
> {
> x->x_onset = f;
> array_max_bang(x);
> }
> 
> 
> In the float method it looks like the onset is never actually assigned in
> the x_rangeop member of the t_array_max struct, so array_rangeop_getrange
> can't set the firstitem pointer to anything but its init value.
> 
> 
> Thanks,
> 
> Matt

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list