Re: [PD] Pd on Tiny Core Linux on Raspberry Pi

[Thomas Grill]

Dear all,
i have made a picore package for the pure data binaries:
http://l.g.org/puredata_tcz

The files need to be put into the tce/optional folder, and enabled in 
tce/onboot.lst if desired.

It is compiled for alsa only with -Os optimization and no specific architecture.
It can use tcl/tk if installed, fftw3 is currently not used.

Please let me know if it works for you.
If it does i will submit it to the official picore repo.

best, Thomas

--
Thomas Grill
http://g.org



> Am 03.02.2018 um 07:45 schrieb Chris McCormick :
> 
> Hi all,
> 
> This is fan mail for Pd on Tiny Core Linux onn Raspberry Pi.
> 
> TCL is a 50 megabyte GNU/Linux distribution which is immutable-by-default and 
> runs very well on the Raspberry Pi.
> 
> I managed to compile Pd and got it to output a test tone which is why I am 
> posting here. To do it yourself:
> 
> * Install the alsa packages
> * Install the compiletc package
> * Compile Pd with `make -f makefile.gnu` inside the src directory
> * Run `pd -nogui mypatch.pd` from the bin directory
> 
> If you want to launch a Pd patch at startup add your command to 
> /opt/bootlocal.sh
> 
> So far this seems like fertile ground as an alternative to the Raspbian 
> distribution with its multiple-gigabyte bloat. Seems perfect for embedded Pd 
> devices like guitar pedals, synths, and what-not.
> 
> Tiny Core Linux does not use systemd.
> 
> Cheers,
> 
> Chris.
> 
> --
> http://mccormick.cx/
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd on Tiny Core Linux on Raspberry Pi

[Thomas Grill]

Hi Andy,
i think what you are looking for is called "persistent /home and/or /opt"
http://wiki.tinycorelinux.net/wiki:persistent_home

best, Thomas



> Am 03.02.2018 um 19:14 schrieb Andy Farnell :
> 
> 
> Good to know that works Chris. The immutability is a
> double edged sword. Did you get anywhere with the Core
> documentation on making a more standard read-write install?
> I kinda gave yp last time I tried.
> 
> (immutable) Core is great on RPi zero boards
> 
> cheers,
> Andy
> 
> 
> On Sat, Feb 03, 2018 at 02:45:50PM +0800, Chris McCormick wrote:
>> Hi all,
>> 
>> This is fan mail for Pd on Tiny Core Linux onn Raspberry Pi.
>> 
>> TCL is a 50 megabyte GNU/Linux distribution which is
>> immutable-by-default and runs very well on the Raspberry Pi.
>> 
>> I managed to compile Pd and got it to output a test tone which is
>> why I am posting here. To do it yourself:
>> 
>> * Install the alsa packages
>> * Install the compiletc package
>> * Compile Pd with `make -f makefile.gnu` inside the src directory
>> * Run `pd -nogui mypatch.pd` from the bin directory
>> 
>> If you want to launch a Pd patch at startup add your command to
>> /opt/bootlocal.sh
>> 
>> So far this seems like fertile ground as an alternative to the
>> Raspbian distribution with its multiple-gigabyte bloat. Seems
>> perfect for embedded Pd devices like guitar pedals, synths, and
>> what-not.
>> 
>> Tiny Core Linux does not use systemd.
>> 
>> Cheers,
>> 
>> Chris.
>> 
>> --
>> http://mccormick.cx/
>> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Son, 2018-02-04 at 13:12 +, Dario Sanfilippo wrote:
> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few
> other things too: 256 instantiations of the feedback loop in my
> abstractions are around 44% load whereas the same number of [fexpr~
> max($x1[0], $y[-1]*$x2[0])] are peaking at 95%.

Ah, good to know. There is no point in doing this [fexpr~] then. Thanks
for testing.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Alexandre Torres Porres]

hi, I tried only using fexpr~, here's what I got

[image: Imagem inline 1]

#N canvas 627 57 454 302 10;
#X obj 352 105 v n_\$0;
#X floatatom 352 74 5 0 0 0 - - -, f 5;
#X obj 59 117 v count_\$0;
#X obj 132 112 fexpr~ count_\$0 = $y2[-1] + 1 \; if(count_\$0 > n_\$0
\, 1 \, count_\$0);
#X obj 34 153 fexpr~ max($x1[0] \, if($x2[-1] \, $y1[-1] \, -1)) \;
;
#X obj 270 195 samphold~;
#X obj 321 154 expr~ $v1 != 1;
#X obj 34 25 noise~;
#X text 80 25 <= input;
#X text 342 249 <= output;
#X obj 270 246 else/display~;
#X text 177 73 'n' number of samples >;
#X connect 1 0 0 0;
#X connect 3 1 6 0;
#X connect 4 0 5 0;
#X connect 5 0 10 0;
#X connect 6 0 4 1;
#X connect 6 0 5 1;
#X connect 7 0 4 0;


2018-02-04 12:56 GMT-02:00 Dario Sanfilippo :

> That's certainly the way to go for efficiency: 256 rpole~ objects are
> about 10% load against 44% load of the PD-implemented counterpart.
>
> D
>
>
> On 4 February 2018 at 14:41, Matt Davey  wrote:
>
>> Really at that point, you’d have to be asking youself if there is any way
>> to use an external.
>>
>>
>> On Sunday, February 4, 2018, Dario Sanfilippo 
>> wrote:
>>
>>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
>>> things too: 256 instantiations of the feedback loop in my abstractions are
>>> around 44% load whereas the same number of [fexpr~ max($x1[0],
>>> $y[-1]*$x2[0])] are peaking at 95%.
>>>
>>> D
>>>
>>>
>>> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>>>
 On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
 > There's an implementation of a peak holder in this blog post: http://
 > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
 > pure-data.

 BTW: the peak envelope part could be also implemented using fexpr~:

 [fexpr~ max($x1[0], ($y[-1]*$f2)]

 This has the advantage of not requiring a re-blocked subpatch with
 blocksize=1. However, I wonder which is computationally less expensive.
 Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?

 Roman
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
 stinfo/pd-list


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

Re: [PD] max value of last n samples

[Dario Sanfilippo]

That's certainly the way to go for efficiency: 256 rpole~ objects are about
10% load against 44% load of the PD-implemented counterpart.

D


On 4 February 2018 at 14:41, Matt Davey  wrote:

> Really at that point, you’d have to be asking youself if there is any way
> to use an external.
>
>
> On Sunday, February 4, 2018, Dario Sanfilippo 
> wrote:
>
>> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
>> things too: 256 instantiations of the feedback loop in my abstractions are
>> around 44% load whereas the same number of [fexpr~ max($x1[0],
>> $y[-1]*$x2[0])] are peaking at 95%.
>>
>> D
>>
>>
>> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>>
>>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
>>> > There's an implementation of a peak holder in this blog post: http://
>>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
>>> > pure-data.
>>>
>>> BTW: the peak envelope part could be also implemented using fexpr~:
>>>
>>> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>>>
>>> This has the advantage of not requiring a re-blocked subpatch with
>>> blocksize=1. However, I wonder which is computationally less expensive.
>>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>>>
>>> Roman
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Matt Davey]

Really at that point, you’d have to be asking youself if there is any way
to use an external.

On Sunday, February 4, 2018, Dario Sanfilippo 
wrote:

> Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
> things too: 256 instantiations of the feedback loop in my abstractions are
> around 44% load whereas the same number of [fexpr~ max($x1[0],
> $y[-1]*$x2[0])] are peaking at 95%.
>
> D
>
>
> On 4 February 2018 at 12:33, Roman Haefeli  wrote:
>
>> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
>> > There's an implementation of a peak holder in this blog post: http://
>> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
>> > pure-data.
>>
>> BTW: the peak envelope part could be also implemented using fexpr~:
>>
>> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>>
>> This has the advantage of not requiring a re-blocked subpatch with
>> blocksize=1. However, I wonder which is computationally less expensive.
>> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>>
>> Roman
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Dario Sanfilippo]

Hi, Roman. I guess that fexpr~ implies block 1 but probably a few other
things too: 256 instantiations of the feedback loop in my abstractions are
around 44% load whereas the same number of [fexpr~ max($x1[0],
$y[-1]*$x2[0])] are peaking at 95%.

D


On 4 February 2018 at 12:33, Roman Haefeli  wrote:

> On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> > There's an implementation of a peak holder in this blog post: http://
> > dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> > pure-data.
>
> BTW: the peak envelope part could be also implemented using fexpr~:
>
> [fexpr~ max($x1[0], ($y[-1]*$f2)]
>
> This has the advantage of not requiring a re-blocked subpatch with
> blocksize=1. However, I wonder which is computationally less expensive.
> Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] max value of last n samples

[Roman Haefeli]

On Fre, 2018-02-02 at 18:31 +, Dario Sanfilippo wrote:
> There's an implementation of a peak holder in this blog post: http://
> dariosanfilippo.tumblr.com/post/162523174771/lookahead-limiting-in-
> pure-data. 

BTW: the peak envelope part could be also implemented using fexpr~:

[fexpr~ max($x1[0], ($y[-1]*$f2)]

This has the advantage of not requiring a re-blocked subpatch with
blocksize=1. However, I wonder which is computationally less expensive.
Is there a rule of thumb whether [fexpr~] or [block~ 1] is faster?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list