Re: [PD] compiling extenrals for mac 32 bits

[Alexandre Torres Porres]

Em seg., 19 de out. de 2020 às 06:31, Dan Wilcox 
escreveu:

> you just have to set the fat binary extension when building on macOS (and
> not other platforms) in your makefile:
>
> extension=d_fat
>

Tried in the makefile and it didn't work, but then I thought you may have
meant when doing "make install" and it worked ;)

I see now that I have binaries that work for both pd 32 and 64 bits.

Now, I had already uploaded to deken my previous compilation, which
resulted in "Darwin-amd64-32". The compilation had also generated
"pd_darwin" extensions. Now I have generated
"(Darwin-amd64-32)(Darwin-i386-32)" and .d_fat!

Now I should just delete the first "Darwin-amd64-32/pd_darwin" from deken,
right? I just want to be clear there's no reason to keep it. If my previous
package is better in any way or something (like "faster"?). I assume it
would show both options for download and people will just be confused if
there's no reason to pick one over the other.

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

Re: [PD] quacktrip - jacktrip (low-latency audio) from behind home routers

[Ed Kelly via Pd-list]

Hey list,
I've been using quacktrip in live online performances with Simon Limbrick 
(percussion) - it's much easier to use than jacktrip and very effective, 
although I can confirm there are occasional dropouts - considering we are in 
completely different parts of the UK this is pretty unremarkable. It's 
advisable to increase blocksize and FIFO length, perhaps even checking the 2x 
button.
You can hear some of our work 
here:https://www.youtube.com/watch?v=9GDMUag4Q_E_channel=PaulSimonLimbrick

Cheers,Ed

_-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Sunday, 18 October 2020, 15:07:40 BST, Edwin van der Heide 
 wrote:  
 
 Hi Miller,

I’ve started playing around with quacktrip 0.91 today and am having a lot of 
fun!

I have been interconnecting a Macbook Pro 2009 and a Macbook Pro 2016, both on 
the same local network, but one using a VPN connection from the Netherlands to 
Latvia (and back) to simulate a bit of distance.

Two observations:
- Sometimes a glitch occurs without the dropout counter increasing. I’m not 
sure if this occurs because a package is missing and the counter is not 
updated, or that the package is there and something else goes wrong. 
- The number boxes are updated at a fast rate and that takes a bit of CPU. The 
audio networking itself is actually not very cpu intensive.

I could imagine two additions:
- option to choose between 16 and 24 bit quality
- create the possibility to send audio in one direction only instead of always 
in both directions.

Cheers!

Edwin

p.s. should I assume that foo.ucsd.edu is usually up or would you recommend to 
run my own server?


> On 2 Jun 2020, at 18:46, Miller Puckette via Pd-list  
> wrote:
> 
> To Pd list -
> 
> This is very preliminary, but some of you might be interested in this.  I've
> been working for the last month or two on making an easy-ti-use implementation
> of jacktrip to allow people stuck at home to play music together.  A test
> version of this is available on msp.ucsd.edu/tools/quacktrip .
> 
> The jacktrip implementation is based on the one in TPM by Roman Haefeli and
> Johannes Schuett (sorry for the no-diacritical spelling).
> 
> It's been tried out by 4 or 5 people so far, seems to work with some
> hiccups.  I'll be getting back to work on it after Pd 0.51-0 gets finalized.
> 
> cheers
> Miller
> 
> 
> 
> ___
> 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
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Startup times to run Pd patch on Raspberry Pi

[Winfried Ritsch]

Am Montag, 19. Oktober 2020, 11:44:20 CEST schrieb Roman Haefeli:
> On Mon, 2020-10-19 at 11:08 +0200, Winfried Ritsch wrote:
> > algo@DIYasb5:~$ systemd-analyze blame
> > 
> >  10.009s jackd.service
> 
> That seems long. How does the systemd unit file looks like? It appears
> jackd fires up quicker (<1s) on my old RPi 3, but then I might be
> fooled by the fact that it has been loaded before and it would require
> more time after boot.
> 
thanks for the info,
 the problem was not really correct addressed:

In experiments I saw it will take 10 seconds to savely start pd after jackd
So I put an 10s in jackd.service:
   ExecStartPost=/bin/sleep ${WAIT_AFTER_START}

The problem is jackd either provides dbus or socket-connection socket to late 
or the connection is not established because some parameters didnt stabilize, 
such as sound card binding with samplerate... but I didnt try to hard to find 
the reason, since for this purpose it was sufficient. 

But for new applications (streaming box) I want a faster boot up 

mfg
  winfried 



> Roman


-- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- rit...@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
--



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

Re: [PD] Startup times to run Pd patch on Raspberry Pi

[Roman Haefeli]

On Mon, 2020-10-19 at 11:08 +0200, Winfried Ritsch wrote:

> algo@DIYasb5:~$ systemd-analyze blame
>  10.009s jackd.service


That seems long. How does the systemd unit file looks like? It appears
jackd fires up quicker (<1s) on my old RPi 3, but then I might be
fooled by the fact that it has been loaded before and it would require
more time after boot. 

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] compiling extenrals for mac 32 bits

[Dan Wilcox]

> On Oct 19, 2020, at 3:14 AM, Alexandre Torres Porres  wrote:
> 
> 
> 
> Em dom., 18 de out. de 2020 às 07:09, Dan Wilcox  > escreveu:
> Newer macOS versions can't run 32 bit code and so the compiler, as far as I 
> know, won't build 32 bit versions. If you are running macOS 10.15, which I 
> believe you are, you cannot build for 32 bit anymore.
> 
> I'm in 10.14.6 actually

Ok, so 32 bit compilation should not be an issue. It's also one reason why I am 
still on 10.14 for now.

> In any case, you may have to move to a dedicated build machine which stays on 
> an older version of macOS, say 10.14, if you personal machine is to run the 
> latest version.
> 
> no problem, here I am and I should keep it that way :)
> 
> so, what does this change? What do I have to do?

It just means you have to tell pdlibuild you want a "fat binary." This used to 
be the default but Katja updated pdlibbuilder 0.6 to use the system 
architecture. This is the same approach used by Xcode for some time and is 
required as trying to build for i386 will just fail on macOS 10.15+.

It might need to be better documented in the README, but you just have to set 
the fat binary extension when building on macOS (and not other platforms) in 
your makefile:

extension=d_fat

> On a side note, who does still use 32 bits on mac and why? I assume is mostly 
> because you may want to run old externals that are only available for 32 
> bits, right? If so, I wonder which libraries are actually relevant and if we 
> should just try and build them for 64 bits... since from 10.15 and on they 
> can't even run any more (if I got things correctly). 

Mmm yes and no. There are plenty of people using older machines around so its 
not like there are *no* users of 32 bit Pd. However, I think the numbers have 
definitely shifted over time as we have 64 bit builds of Pd available and many 
of the most used externals form extended have been updated and released in 64 
bit.

It's really up to how much maintenance can you support for systems you and your 
team may not use personally. I think it's reasonable to find a point to where 
you stop 32 bit builds and only move forward with 64 bit releases. If there is 
no additional work for y'all to unofficial support compiling in 32 bit and the 
sources are available, people can also make 32 bit builds as required. This is 
why the decentralized model for externals is great, even if it's taken more 
time to get things going after extended.

That being said, modern Pd is compilable on Windows XP so who knows who is 
using your 32 bit builds. :) It's up to you.


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] Startup times to run Pd patch on Raspberry Pi

[Winfried Ritsch]

Late follow up for topic a my experiences and rfc.

roughly documented, in  
 https://git.iem.at/cm/diyasb 
see firmware/debian ...

With an Olimex A64, (quite like RaspPi3, but industrial specs), I run Debian 
(Armbian) now on many of them over 6 month outdoors, so quite stable and
they boot in 20sec-30sec from internal emmc-flash with usb-sound devices.
It quite fast (14s sec), except for Pd patch waiting for jackd 5-10 seconds 
with my systemd scripts, so there is room for improvement, systemd-analyze 
says::

algo@DIYasb5:~$ systemd-analyze 
   Startup finished in 6.013s (kernel) + 27.266s (userspace) = 33.280s 
   graphical.target reached after 14.179s in userspace

in details it blames:

algo@DIYasb5:~$ systemd-analyze blame
 10.009s jackd.service
  5.108s olsrd.service
  3.271s armbian-ramlog.service
  3.018s pd_stream.service
  2.547s armbian-zram-config.service
  1.829s dev-mmcblk1p1.device
   948ms keyboard-setup.service
   872ms ifupdown-pre.service
   669ms systemd-udev-trigger.service
   527ms man-db.service
   521ms networking.service
   510ms systemd-journald.service
   423ms resolvconf.service
   356ms darkice.service

note: olsrd for network-mesg is not needed so graphical.target is after pd is 
started with no-gui.

to start pd faster we could theoretically rearrange it,  after sound.target 
and jackd.service, but I didn't succeed.



Any hints on optimize the systemd scripts are welcomed. 

mfg 
   winfried



Am Dienstag, 6. Oktober 2020, 17:29:24 CEST schrieb Yann Seznec:
> Thanks for all the thoughts and feedback. I should have said that my 60
> second boot time is when I use the Pi headless, console-only, running the
> patch with -nogui.
> 
> I’ll have a look at disabling some things as suggested, and I’ll report back
> if I make any significant progress! I imagine I’m not alone in this quest
> so I’ll try and document it somehow, or at least post it here for future
> generations.
> 
> I really like the look of piCore OS too. It seems like the right approach
> for me in the long run, though I am wary of jumping into a new system.
> Maybe eventually we can make our own pdCore OS :)
> > On Oct 5, 2020, at 5:27 PM, Thomas Grill  wrote:
> > 
> > Hi all,
> > i am a big fan of the piCore os. [1]
> > That is a stripped down read-only linux distro with loadable modules for
> > alsa, pure data etc.. Boot times are considerable shorter than with
> > raspbian.
> > Of course it also needs some dedication to get used with it.
> > 
> > I have compiled pd, jack and libfftw3 for piCore 11, to be found here:
> > https://g.org/data/dev/picore/piCore-11/
> > 
> > best, Thomas
> > 
> > [1] http://tinycorelinux.net/11.x/armv6/releases/RPi/
> > 
> >> Am 05.10.2020 um 17:05 schrieb Martin Peach :
> >> 
> >> It takes about a minute for the pi to boot. There is not much you can
> >> do about that.
> >> 
> >> Martiin
> >> 
> >> On Mon, Oct 5, 2020 at 11:03 AM Yann Seznec  wrote:
> >>> Hi everyone, long time reader first time writer.
> >>> 
> >>> I’m wondering what people’s experiences are with regards to the startup
> >>> time for running a patch on a raspberry pi.
> >>> 
> >>> For various reasons I’ve started to use Patchbox OS to auto-run my
> >>> patches on startup, which is very reliable and consistent however it
> >>> usually takes about 60 seconds from switching on to making sound. This
> >>> is on various models of Raspberry Pi 3.
> >>> 
> >>> Has anyone managed to speed this up? I haven’t tried the Raspi 4,
> >>> perhaps that is significantly faster?
> >>> 
> >>> Thanks,
> >>> Yann
> >>> 
> >>> 
> >>> ___
> >>> 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> 
> > --
> > Thomas Grill
> > http://g.org
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list


-- 
--
- ao.Univ.Prof. DI Winfried Ritsch 
- rit...@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 
--



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