Re: [PD] md5 object?

[Marco Hugo Schretter]

hi,

good to hear that pjlink is in use with pd!

resolved it? i'm working on it. i'm controlling several
panasonic d5000 projectors at work with pd. it is definitely
possible with the shell object but i often must use windows
to do pjlink control from ableton with pd and so the shell
object doesn't work. i use pjlink in a theater piece with
livecam etc...and always worked but i turned pjlink security
off (not the best solution but stable).

i'll try to do some documentation soon so maybe we can
solve the md5 thing. there are some opensource projects
which provide all the basic c/c++ code for an md5 external as
i found out. time will come.

@chris: thanks for sha1 example

liebe grüße
marco

Am 27.10.17 um 04:20 schrieb Chris McCormick:

Hi Jonas,

This patch contains a subpatch which computes the SHA1 hash of the input:

https://sourceforge.net/projects/websocketserverinapatch/files/

Not exactly what you need but maybe you can use sha1 instead, or maybe 
you can adapt it.


Cheers,

Chris.

On 27/10/17 04:46, hi via Pd-list wrote:

Dear list,

I am trying to develop a pjlink projector controller and for this I 
need a way to create a md5 hash. Is there an object or a way to do 
this in Pd?


jonas
___
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] glitches when streaming UDP

[Roman Haefeli]

On Mit, 2018-02-07 at 10:41 -0500, Martin Peach wrote:
> On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli  
> > I tried: 
> >  * turning hyperthreading off
> >  * putting pd and jackd on the same core
> >  * putting pd and jackd on different cores
> > 
> > but those configurations don't seem to affect the current situation
> > at
> > all.
> > 
> There's also wish, the tcl/tk component.

To eliminate as many factors as possible, I run [adc~]-[dac~] in:

 pd -noprefs -nogui -rt -jack -channels 2 -open shortcircuit.pd

But even when I run with GUI, wish and pd communicate through a network
socket. It shouldn't matter if they share a core, or should it?

> Yes it sounds like the things go to sleep when nothing happens for a
> few nanoseconds or something.

Exactly, and I haven't the slightest clue what it is.

> It should be documented somewhere on kernel.org.

I don't feel competent enough for that.

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] glitches when streaming UDP

[Martin Peach]

On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli  wrote:

> On Mit, 2018-02-07 at 09:46 -0500, Martin Peach wrote:
>
> > Maybe there's a way to force all the Pd-related processes to run on
> > the same core, as it could be that the transfer of memory from one to
> > the other causes glitches, so if jackd is on a different core than Pd
> > there will be latency as they transfer access to the buffer from one
> > to the other. Just guessing...
>
>
> I tried:
>  * turning hyperthreading off
>  * putting pd and jackd on the same core
>  * putting pd and jackd on different cores
>
> but those configurations don't seem to affect the current situation at
> all.
>
> There's also wish, the tcl/tk component.


> Please someone correct me here, but I think it does not matter if pd
> and jackd run on the same core, since they seem to communicate through
> /dev/shm, so there is no gain to be made by being closer together. I'd
> say it makes even sense to separate them so that overall more CPU power
> is available for both.
>
> Also, the fact the running x instances of 'yes' in the background helps
> indicates that the problem is not the communication between pd and
> jackd.
>
> Yes it sounds like the things go to sleep when nothing happens for a few
nanoseconds or something.
It should be documented somewhere on kernel.org.

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

Re: [PD] glitches when streaming UDP

[Martin Peach]

On Wed, Feb 7, 2018 at 9:26 AM, Roman Haefeli  wrote:

> On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:
> > On 30/01/2018 11:07, Roman Haefeli wrote:
> > >
> > > On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
> > >
> > > >
> > > > I'm working on a patch that transmits audio through UDP. The
> > > > patch
> > > > runs
> > > > totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK
> > > > as
> > > > back-end. On the Linux machines I tested (all Ubuntu 16.04) with
> > > > the
> > > > same version of Pd I get a lot of glitches, although I'm using
> > > > very
> > > > similar Jack settings (128 frames/period, 3 periods).
> > > Update:
> > > My personal, somewhat outdated laptop from 2007 has absolutely
> > > stable
> > > performance with same patch, same Pd version, same OS, same kernel.
> > > To
> > > be clear: It's only Pd that performs well on one computer and not
> > > so
> > > well on others. I get glitch-free audio with Ardour on all tested
> > > computers. So I wonder what circumstances affect specifically Pd.
> > > It's
> > > a pity the most powerful computer I have access to is in its
> > > current
> > > state not suitable for Pd projects :-(
> > One thing to try from totally non-scientific personal experience
> > would
> > be to look into CPU scaling stuff when using Pd. The fact that an
> > old
> > machine works well possibly hints that this might be the culprit, so
> > worth trying. I experimented with this when pushing my Granita
> > granulator with realtime input being fed to the buffer and trying to
> > eliminate as much as possilbe "smart" CPU stuff improved things quite
> > a
> > lot... On my previous laptop I could set various governors on my
> > current
> > one there is only powersave and performance, the latter should work,
> > but
> > also trying to set a fixed frequency... You have to experiment a bit.
>
> Thanks for mentioning that. Setting the governor to 'performance' for
> all cores is part of my standard setup when going into 'performance'
> mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I
> need the scaling governor to set to 'performance'. To my non-scientific
> eye it looks like Pd in realtime mode has a higher priority than the
> service controlling CPU frequency, so that switching to a new frequency
> would happen only after Pd's need for it is over.
>
> The issue I'm having here is not related to CPU frequency scaling (at
> least not exclusively). Even when all cores run under 'performance' and
> at maximum clock speed, I get crackles with the new laptop (CPU: Intel
> Core i5-7300U). Yet, the only reliable way known to me so far to get
> running Pd crackle-free is to run four instances of 'yes > /dev/null
> &'. This seems to keep whatever resource Pd needs to access quickly
> awake and available. While those four instances of 'yes' are running in
> the background, it doesn't matter what governor I set since they keep

the cores at their maximum frequency anyway.
>
>
Maybe there's a way to force all the Pd-related processes to run on the
same core, as it could be that the transfer of memory from one to the other
causes glitches, so if jackd is on a different core than Pd there will be
latency as they transfer access to the buffer from one to the other. Just
guessing...

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

Re: [PD] glitches when streaming UDP

[Roman Haefeli]

On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:
> On 30/01/2018 11:07, Roman Haefeli wrote:
> > 
> > On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
> > 
> > > 
> > > I'm working on a patch that transmits audio through UDP. The
> > > patch
> > > runs
> > > totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK
> > > as
> > > back-end. On the Linux machines I tested (all Ubuntu 16.04) with
> > > the
> > > same version of Pd I get a lot of glitches, although I'm using
> > > very
> > > similar Jack settings (128 frames/period, 3 periods).
> > Update:
> > My personal, somewhat outdated laptop from 2007 has absolutely
> > stable
> > performance with same patch, same Pd version, same OS, same kernel.
> > To
> > be clear: It's only Pd that performs well on one computer and not
> > so
> > well on others. I get glitch-free audio with Ardour on all tested
> > computers. So I wonder what circumstances affect specifically Pd.
> > It's
> > a pity the most powerful computer I have access to is in its
> > current
> > state not suitable for Pd projects :-(
> One thing to try from totally non-scientific personal experience
> would 
> be to look into CPU scaling stuff when using Pd. The fact that an
> old 
> machine works well possibly hints that this might be the culprit, so 
> worth trying. I experimented with this when pushing my Granita 
> granulator with realtime input being fed to the buffer and trying to 
> eliminate as much as possilbe "smart" CPU stuff improved things quite
> a 
> lot... On my previous laptop I could set various governors on my
> current 
> one there is only powersave and performance, the latter should work,
> but 
> also trying to set a fixed frequency... You have to experiment a bit.

Thanks for mentioning that. Setting the governor to 'performance' for
all cores is part of my standard setup when going into 'performance'
mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I
need the scaling governor to set to 'performance'. To my non-scientific 
eye it looks like Pd in realtime mode has a higher priority than the
service controlling CPU frequency, so that switching to a new frequency
would happen only after Pd's need for it is over.

The issue I'm having here is not related to CPU frequency scaling (at
least not exclusively). Even when all cores run under 'performance' and
at maximum clock speed, I get crackles with the new laptop (CPU: Intel
Core i5-7300U). Yet, the only reliable way known to me so far to get
running Pd crackle-free is to run four instances of 'yes > /dev/null
&'. This seems to keep whatever resource Pd needs to access quickly
awake and available. While those four instances of 'yes' are running in
the background, it doesn't matter what governor I set since they keep
the cores at their maximum frequency anyway. 

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] glitches when streaming UDP

[Lorenzo Sutton]

On 30/01/2018 11:07, Roman Haefeli wrote:

On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:


I'm working on a patch that transmits audio through UDP. The patch
runs
totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK as
back-end. On the Linux machines I tested (all Ubuntu 16.04) with the
same version of Pd I get a lot of glitches, although I'm using very
similar Jack settings (128 frames/period, 3 periods).


Update:
My personal, somewhat outdated laptop from 2007 has absolutely stable
performance with same patch, same Pd version, same OS, same kernel. To
be clear: It's only Pd that performs well on one computer and not so
well on others. I get glitch-free audio with Ardour on all tested
computers. So I wonder what circumstances affect specifically Pd. It's
a pity the most powerful computer I have access to is in its current
state not suitable for Pd projects :-(


One thing to try from totally non-scientific personal experience would 
be to look into CPU scaling stuff when using Pd. The fact that an old 
machine works well possibly hints that this might be the culprit, so 
worth trying. I experimented with this when pushing my Granita 
granulator with realtime input being fed to the buffer and trying to 
eliminate as much as possilbe "smart" CPU stuff improved things quite a 
lot... On my previous laptop I could set various governors on my current 
one there is only powersave and performance, the latter should work, but 
also trying to set a fixed frequency... You have to experiment a bit.


Kernel documentation:
https://www.kernel.org/doc/html/v4.14/admin-guide/pm/cpufreq.html

Arch-specific but possibly some interesting general information:
https://wiki.archlinux.org/index.php/CPU_frequency_scaling

Also for Debian (and possibly Ubuntu):
https://wiki.debian.org/HowTo/CpuFrequencyScaling

Red Hat:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/power_management_guide/cpufreq_governors

My two cents.
Lorenzo

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

Looks like an issue with autoconf of your system. If we used a dist tarball 
with pregenerated configure scripts, this probably wouldn't be an issue since 
then autoconf and automaker are not needed, just gcc and make.

If you have any more time, you could try building a dist tarball on your main 
system and then build Pd with it using configure/make on the pi. Building the 
tarball is:

./autogen.sh
./configure
make dist

That gives you a pd-0.48.1.tgz with the pregenerated configure scripts.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com


> On Feb 7, 2018, at 8:30 AM, Chris McCormick  wrote:
> 
> Hi Dan,
> 
> On 03/02/18 21:15, Dan Wilcox wrote:
> > Out of curiosity, does the autotools build work as well?
> 
> I got this when I tried:
> 
> tc@box:~/pure-data$ autoconf
> configure.ac:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
>  If this token and others are legitimate, please use m4_pattern_allow.
>  See the Autoconf documentation.
> configure.ac:149: error: possibly undefined macro: AM_CONDITIONAL
> configure.ac:162: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
> configure.ac:163: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
> configure.ac:164: error: possibly undefined macro: AC_PROG_LIBTOOL
> configure.ac:230: error: possibly undefined macro: AC_CHECK_LIBM
> 
> Then when I tried to run configure:
> 
> tc@box:~/pure-data$ ./configure
> configure: error: cannot find install-sh, install.sh, or shtool in m4/config 
> "."/m4/config
> 
> I guess there are some additional build dependencies I'd need to install to 
> get this working.
> 
> For now the old makefile.gnu route works great on this platform.
> 
> Cheers,
> 
> Chris.
> 
> -- 
> http://mccormick.cx/

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