[PD] sensing whether a window is active

[Liam Goodacre]

Hi all

Is there a way to sense whether a parent-level window is active? By "active" I 
mean that the window is in focus with the title bar highlighted.

[cyclone/active] is able to sense whether the current window is active, but I 
specifically need to know if the parent (grandparent, etc) window is active.

Solutions involving externals are welcome.
___
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

[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


signature.asc
Description: Digital signature
___
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 Sam, 2018-02-03 at 12:42 +, Dario Sanfilippo wrote:
> I see what you mean, Roman. So you'd need the N-size block to be
> processed beforehand, which would imply an N-size delay in the
> output, is that right? 

Actually, your peak holder implementation does the job well for me. I
was (and am) still curious, though, how to implement what I initially
asked for which is apparently called 'sliding window maximum' [1].

What I like about your implementation is that you managed to start a
timer when a peak is detected and you do that in the signal domain. 

> I haven't thought of it, no idea whether that could be achieved by
> changing the feedback period in the peak holder and/or adding a delay
> in the input. Maybe I'll try something later.

If you're curious, that's fine, but it's not necessary to spend more
time for my case. I'm happy with your peak holder ;-)

Roman

[1] https://articles.leetcode.com/sliding-window-maximum/


> Cheers,
> Dario
> 
> On 3 February 2018 at 09:33, Roman Haefeli 
> wrote:
> > On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> > > Thanks, Roman.
> > >
> > > On 2 February 2018 at 21:28, 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. I remember testing it but please let me know if
> > you
> > > > find a
> > > > > bug.
> > > >
> > > > Very nice write up. Thanks for sharing.
> > > >
> > > > > The current peak is replaced to whatever the input is after a
> > > > desired
> > > > > time, and the counter is reset whenever a new peak is found.
> > It
> > > > > should be easy to change it so that the peak is reset
> > > > periodically.
> > > >
> > > > It's not exactly equivalent with what I've asked, since your
> > > > implementation only takes new peaks into account after the hold
> > > > period
> > > > has ended. 
> > > Perhaps my wording in the previous email was confusing: what
> > happens
> > > is that every new peak will update the output immediately, and
> > > whenever that happens the countdown starts so that, should no
> > other
> > > peak be detected after that time, the output will be set to
> > whatever
> > > the input is in that moment.
> > >  
> > > > Assume an input signal consisting of a series of 1-sample
> > > > impulses with a period that is slightly lower than the hold
> > period.
> > > > The
> > > > output signal has a gap before each second impulse. For the use
> > > > case in
> > > > your article (which is also the use case I'm interested in),
> > that
> > > > doesn't matter much, because the peak holder signal is fed to a
> > > > peak
> > > > enveloper which somewhat masks those gaps.
> > > In that case, we should expect a full-amp DC out of the peak
> > holder
> > > for the impulses are faster than the hold time, and that's what
> > we
> > > actually get:
> > 
> > 
> > Yes, correct. If the peaks  reach the same level or are higher than
> > the
> > ones before, then the hold period is prolonged. But when they have
> > less
> > amplitude than the ones before, gaps appear. See:
> > 
> > https://netpd.org/~roman/tmp/peakholder_gaps.png
> > 
> > With a true max(x[0-(-N)], a downward stairway would appear and
> > there
> > wouldn't be any gaps. 
> > 
> > As I said, that is only small difference and for the purpose of a
> > look-
> > ahead limiter it probably doesn't matter that much.
> > 
> > Roman
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 

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] Pd on Tiny Core Linux on Raspberry Pi

[Dan Wilcox]

Out of curiosity, does the autotools build work as well?

And yes, a simple embedded-only distort would be *very* useful as I had 
problems with performance turning Raspbian in the past.

> On Feb 3, 2018, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Sat, 3 Feb 2018 14:45:50 +0800
> From: Chris McCormick >
> To: "pd-list@lists.iem.at " 
> >
> Subject: [PD] Pd on Tiny Core Linux on Raspberry Pi
> Message-ID: <59001321-177a-dfc0-a19a-b0cb01e7f...@mccormick.cx 
> >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 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.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
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]

I see what you mean, Roman. So you'd need the N-size block to be processed
beforehand, which would imply an N-size delay in the output, is that right?
I haven't thought of it, no idea whether that could be achieved by changing
the feedback period in the peak holder and/or adding a delay in the input.
Maybe I'll try something later.

Cheers,
Dario

On 3 February 2018 at 09:33, Roman Haefeli  wrote:

> On Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> > Thanks, Roman.
> >
> > On 2 February 2018 at 21:28, 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. I remember testing it but please let me know if you
> > > find a
> > > > bug.
> > >
> > > Very nice write up. Thanks for sharing.
> > >
> > > > The current peak is replaced to whatever the input is after a
> > > desired
> > > > time, and the counter is reset whenever a new peak is found. It
> > > > should be easy to change it so that the peak is reset
> > > periodically.
> > >
> > > It's not exactly equivalent with what I've asked, since your
> > > implementation only takes new peaks into account after the hold
> > > period
> > > has ended.
> > Perhaps my wording in the previous email was confusing: what happens
> > is that every new peak will update the output immediately, and
> > whenever that happens the countdown starts so that, should no other
> > peak be detected after that time, the output will be set to whatever
> > the input is in that moment.
> >
> > > Assume an input signal consisting of a series of 1-sample
> > > impulses with a period that is slightly lower than the hold period.
> > > The
> > > output signal has a gap before each second impulse. For the use
> > > case in
> > > your article (which is also the use case I'm interested in), that
> > > doesn't matter much, because the peak holder signal is fed to a
> > > peak
> > > enveloper which somewhat masks those gaps.
> > In that case, we should expect a full-amp DC out of the peak holder
> > for the impulses are faster than the hold time, and that's what we
> > actually get:
>
>
> Yes, correct. If the peaks  reach the same level or are higher than the
> ones before, then the hold period is prolonged. But when they have less
> amplitude than the ones before, gaps appear. See:
>
> https://netpd.org/~roman/tmp/peakholder_gaps.png
>
> With a true max(x[0-(-N)], a downward stairway would appear and there
> wouldn't be any gaps.
>
> As I said, that is only small difference and for the purpose of a look-
> ahead limiter it probably doesn't matter that much.
>
> 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 Sam, 2018-02-03 at 02:47 +, Dario Sanfilippo wrote:
> Thanks, Roman.
> 
> On 2 February 2018 at 21:28, 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. I remember testing it but please let me know if you
> > find a
> > > bug.
> > 
> > Very nice write up. Thanks for sharing.
> > 
> > > The current peak is replaced to whatever the input is after a
> > desired
> > > time, and the counter is reset whenever a new peak is found. It
> > > should be easy to change it so that the peak is reset
> > periodically.
> > 
> > It's not exactly equivalent with what I've asked, since your
> > implementation only takes new peaks into account after the hold
> > period
> > has ended. 
> Perhaps my wording in the previous email was confusing: what happens
> is that every new peak will update the output immediately, and
> whenever that happens the countdown starts so that, should no other
> peak be detected after that time, the output will be set to whatever
> the input is in that moment.
>  
> > Assume an input signal consisting of a series of 1-sample
> > impulses with a period that is slightly lower than the hold period.
> > The
> > output signal has a gap before each second impulse. For the use
> > case in
> > your article (which is also the use case I'm interested in), that
> > doesn't matter much, because the peak holder signal is fed to a
> > peak
> > enveloper which somewhat masks those gaps.
> In that case, we should expect a full-amp DC out of the peak holder
> for the impulses are faster than the hold time, and that's what we
> actually get:


Yes, correct. If the peaks  reach the same level or are higher than the
ones before, then the hold period is prolonged. But when they have less
amplitude than the ones before, gaps appear. See:

https://netpd.org/~roman/tmp/peakholder_gaps.png

With a true max(x[0-(-N)], a downward stairway would appear and there
wouldn't be any gaps. 

As I said, that is only small difference and for the purpose of a look-
ahead limiter it probably doesn't matter that much.

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