[LAD] Re: Tape emulation - is it worth the effort ?

[Robin Gareus]

On 2024-10-16 15:23, Fons Adriaensen wrote:

Comments invited !!


Don't forget tape hiss. A bit of low level white noise works magic.

--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

Re: [Sursound] ambdec as plugin (lv2, vst, vst3)

[Robin Gareus]

On 2024-10-03 16:40, Fons Adriaensen wrote:

Would it (as Ardour does) require the plugin to support 'in-place'
processing ? This is still a real PITA in Ardour:


Ardour has not required in-place processing since v6 around 5 years ago.

Yet when possible, a given plugin standards support it, the extra copy 
step can be avoided and the same buffer pointer is passed for input and 
output.



* It doesn't avoid copies nor optimise anything

less memory is touched, so caches can be used more effectively. This 
also leads to faster context switches. If you have a few hundred tracks 
with a couple of plugins on each, things can add up quickly.


As for the issue at hand. The IEM (VST3) plugins run just fine in Ardour 
without in-place processing. For the current ambdec plugins it is LADSPA 
that mandates in-place, isn't it?


--
robin
-- next part --
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: 

___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

[LAD] Re: Pipewire

[Robin Gareus]

Hi Fons,

As far as I know pipewire can not currently meet all 8 of your 
requirements, but I best leave this to Wim to answer.


On 2024-08-13 15:39, Fons Adriaensen wrote:

> 1. Jack2 and some clients are started manually after I login,

So you finally made the switch to jack2?

> and will be running all the time.

just a sidenote. doing that killed the battery on my old laptop.


3. PW will be started manually when required, and I don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.



I do occasionally run pipewire, and do so from its source tree by just 
calling `make run`.


Then I use the following script to launch applications that i want to 
test with pipewire:


```
#!/bin/bash
PW_SRC=$HOME/src/pipewire/
export SPA_PLUGIN_DIR=$PW_SRC/builddir/spa/plugins
export SPA_DATA_DIR=$PW_SRC/spa/plugins
export PIPEWIRE_MODULE_DIR=$PW_SRC/builddir/src/modules
export PIPEWIRE_CONFIG_DIR=$PW_SRC/builddir/src/daemon
export ACP_PATHS_DIR=$PW_SRC/spa/plugins/alsa/mixer/paths
export ACP_PROFILES_DIR=$PW_SRC/spa/plugins/alsa/mixer/profile-sets
export LD_LIBRARY_PATH=$PW_SRC/builddir/pipewire-jack/src/
export 
PATH=$PW_SRC/builddir/pipewire-jack/src/:$PW_SRC/builddir/src/tools:$PATH

exec "$@"
```

e.g pw-src-env pw-jack Ardour8

The downside compared to using the JACK/ALSA bridge is that a already 
running applications will not connect to pipewire after the fact.


Maybe you already knew this, if not I'll take 1/8th of your eternal 
admiration and gratitude :)



> 4. All Jack ports created by PW should be permanent and exist
> as soon as PW is started, so they can be manually connected
> and remain connected even when not in active use.
>
[...]
> 7. I do not expect anything 'automatic' to happen when things
> are plugged in or out.


This is something where macOS' Coreaudio/MIDI shines. Unlike macOS 
Linux/ALSA has no persistent unique IDs for soundcards or MIDI devices. 
ALSA supports hotplug, and first come first server sequential numeric 
IDs. The best you^Wpipewire can do is keep track of cards by name.


So this is not something pipewire can reliably address, until ALSA get 
support to identify cards by vendor and serial-number, and provide a UUID.


Cheers!
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: PandaResampler 0.2.0

[Robin Gareus]

On 2024-06-10 03:16, Yuri wrote:

On 6/9/24 15:47, Marc Lavallée wrote:



Why do people still insist on GNU Tools?



mostly to aid cross compilation. It is still the option that sucks least 
for libraries, notably to specify which symbols to expose in a cross 
platform library. Though meson is catching up.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-25 00:10, Fons Adriaensen wrote:

The way 'fast mode' works in the x42 plugin could give you
a momentary latency of 2 ms, but the average value will be
quite a bit higher and depend on signal content. 


Correct, yet the effective signal delay (which can be measured) needs to 
be reported to the host to align the signal.


No claim is made that the pitch is corrected within that time. The time 
until pitch correction kicks in is obviously [much] longer. For the case 
at hand (live usage) the audible onset is relevant.


If zita-at2 can get that delay down to 10ms, it is likely sufficient.

> Using the same misleading definition of 'latency' I could
> claim whatever I like for zita-at1-0.8.1, even down to zero.

Well, not quite. Calling Retuner::process (), even without any pitch 
correction delays the signal. That delay has to be reported to the host.


This all pertains to how long it takes for the first non-zero sample at 
the input to reach the output of the plugin. The plugin's fast-mode 
decreases that latency for practical purposes.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-24 21:39, Fons Adriaensen wrote:

On Tue, Apr 23, 2024 at 09:24:20PM +0200, Robin Gareus wrote:

On 2024-04-20 16:41, Fons Adriaensen wrote:


With the new logic deciding on forward / backward jumps, the
low latency mode just came for free


Except the latency in zita-at1 0.8.1 is still around ~20ms,


It will be 10 ms when selecting low latency mode.


At 48kHz sample-rate, Retuner::set_lowlat(true) sets Retuner::_latency 
to 1024.



compared 2ms when using the current plugin's "fast mode".


That must be BS. A typical male voice frequency is 125 Hz,
8 ms. So when the algorithm has to skip a cycle, will the
latency change to -6 ms ??

Did anyone ever verify this ? I did a few minutes ago, by
observing in and out on a scope.


Yes, and the documentation and tool-tip of the "fast" control reads
"Reduces latency by allowing initially uncorrected signal."

Probably not what you expect, but it is a nice hack that works well in 
real world live situations.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

On 2024-04-20 16:41, Fons Adriaensen wrote:


With the new logic deciding on forward / backward jumps, the
low latency mode just came for free


Except the latency in zita-at1 0.8.1 is still around ~20ms, compared 2ms 
when using the current plugin's "fast mode".



Re. microtuning individual notes: I don't think the retuning
is ever accurate enough for this to be of any use. Or maybe
I misunderstand what you refer to.


It allows one to detune individual notes, and it is sufficiency accurate 
(not unlike changing the reference pitch or notebias).


Those controls are not exposed in the custom plugin UI. They are control 
ports that show up as automation lines in Ardour, or when editing the 
plugin with a generic control UI.


I think it is best to leave the current plugin as-is. Doing so will not 
break existing sessions using the plugin.



I have started a new project without all the custom patches made to the 
AT1 DSP, and without the variants of the current plugin. The new plugin 
will closely follow the upcoming zita-AT2.




What would be great (in particular for zita-at2) would be
a mode were you can e.g. select a region in Ardour, have it
analysed, present the result graphically so it can be edited,
and finally apply the edited version to the region...


It's highly unlikely that we'll reinvent Melodyne. The hard and time 
consuming part is not the DSP, but the the GUI. It is a full time 
project by itself.


But you never know, someone might step up and file a pull request out of 
the blue. Things like this happened before.


--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

[LAD] Re: Update of zita-at1

[Robin Gareus]

Hi Fons,

it's great to see you have not lot your edge! :)

On 2024-04-20 11:50, Fons Adriaensen wrote:

> The new Retuner class can probably be used without changes
> in the x42-autotuner plugin.
I had a quick look and and sadly it's not that simple. The plugin 
already has a low latency mode, and supports for per note microtuning.


Either I have to backport your bug-fixes, or add the missing features to 
your new version. Then I will have to check that the behavior of 0.8.2 
does not alter the sound of existing sessions using the plugin.


Can you elaborate on the bug fixes that you made?

I'm already looking forward to zita-at2! That will have to be a new 
plugin. So perhaps there is also an option to wait for that to drop.


Thanks for your hard work on this.

--
robin


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Quick follow up: On debian/sid compiling Ardour 8.4 when configured with 
--use-external-libs depends on the following packages:


build-essential
gettext
intltool
itstool
libarchive-dev
libasound2-dev
libaubio-dev
libboost-dev
libcairomm-1.0-dev
libcurl4-gnutls-dev
libcwiid-dev
libdbus-1-dev
libfluidsynth-dev
libglibmm-2.4-dev
libhidapi-dev
libjack-dev
liblilv-dev
liblo-dev
liblrdf0-dev
libltc-dev
libpangomm-1.4-dev
libpulse-dev
libqm-dsp-dev
libreadline-dev
librubberband-dev
libsndfile1-dev
libtag1-dev
libusb-1.0-0-dev
libwebsockets-dev
libxinerama-dev
libxrandr-dev
python3
python-is-python3
vamp-plugin-sdk


Various packages listed currently as build-dep are no longer required.
Notably libsuil-dev, but also ladspa-sdk should be removed. Ardour never 
directly used libserd/sord/sratom either; and liblilv-dev pulls in lv2-dev.


New dependencies are libxrandr-dev and libglibmm-2.4-dev.

Cheers!
robin

On 2024-02-24 15:27, Robin Gareus wrote:

Ardour 8.4 has been released and no longer depends on deprecated GTK2
https://ardour.org/whatsnew.html

Please consider updating Ardour before the autoremoval is triggered.

Thanks,

--
robin - ardour.org

On 2024-02-18 01:43, Erich Eickmeyer wrote:
Apologies, this has *not* been released yet, but will hopefully be 
released in the next week, so please keep an eye on uscan.


Regardless, when it does get released, I will likely send out another 
email. Additionally, packages have been getting removed prematurely 
from Ubuntu prior to removal from Debian, so I'm getting a little 
trigger-happy, hence my email.


Again, apologies for jumping the gun here. :)
Erich

On 2/17/2024 4:22 PM, Erich Eickmeyer wrote:
Ardour 8.3 has been released and no longer depends on deprecated GTK2 
as a modified version is bundled within. 
https://ardour.org/whatsnew83.html


Considering ardour has been scheduled for autoremoval on 06 March 
(#1061203), I highly recommend getting this updated as soon as 
possible to avoid this removal. Since the library is now bundled, the 
dependency on libgtk2.0-dev can be dropped.


Thanks,
Erich
--
Erich Eickmeyer
Ubuntu MOTU
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu









OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Quick follow up: On debian/sid compiling Ardour 8.4 when configured with 
--use-external-libs depends on the following packages:


build-essential
gettext
intltool
itstool
libarchive-dev
libasound2-dev
libaubio-dev
libboost-dev
libcairomm-1.0-dev
libcurl4-gnutls-dev
libcwiid-dev
libdbus-1-dev
libfluidsynth-dev
libglibmm-2.4-dev
libhidapi-dev
libjack-dev
liblilv-dev
liblo-dev
liblrdf0-dev
libltc-dev
libpangomm-1.4-dev
libpulse-dev
libqm-dsp-dev
libreadline-dev
librubberband-dev
libsndfile1-dev
libtag1-dev
libusb-1.0-0-dev
libwebsockets-dev
libxinerama-dev
libxrandr-dev
python3
python-is-python3
vamp-plugin-sdk


Various packages listed currently as build-dep are no longer required.
Notably libsuil-dev, but also ladspa-sdk should be removed. Ardour never 
directly used libserd/sord/sratom either; and liblilv-dev pulls in lv2-dev.


New dependencies are libxrandr-dev and libglibmm-2.4-dev.

Cheers!
robin

On 2024-02-24 15:27, Robin Gareus wrote:

Ardour 8.4 has been released and no longer depends on deprecated GTK2
https://ardour.org/whatsnew.html

Please consider updating Ardour before the autoremoval is triggered.

Thanks,

--
robin - ardour.org

On 2024-02-18 01:43, Erich Eickmeyer wrote:
Apologies, this has *not* been released yet, but will hopefully be 
released in the next week, so please keep an eye on uscan.


Regardless, when it does get released, I will likely send out another 
email. Additionally, packages have been getting removed prematurely 
from Ubuntu prior to removal from Debian, so I'm getting a little 
trigger-happy, hence my email.


Again, apologies for jumping the gun here. :)
Erich

On 2/17/2024 4:22 PM, Erich Eickmeyer wrote:
Ardour 8.3 has been released and no longer depends on deprecated GTK2 
as a modified version is bundled within. 
https://ardour.org/whatsnew83.html


Considering ardour has been scheduled for autoremoval on 06 March 
(#1061203), I highly recommend getting this updated as soon as 
possible to avoid this removal. Since the library is now bundled, the 
dependency on libgtk2.0-dev can be dropped.


Thanks,
Erich
--
Erich Eickmeyer
Ubuntu MOTU
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu









OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Ardour 8.4 has been released and no longer depends on deprecated GTK2
https://ardour.org/whatsnew.html

Please consider updating Ardour before the autoremoval is triggered.

Thanks,

--
robin - ardour.org

On 2024-02-18 01:43, Erich Eickmeyer wrote:
Apologies, this has *not* been released yet, but will hopefully be 
released in the next week, so please keep an eye on uscan.


Regardless, when it does get released, I will likely send out another 
email. Additionally, packages have been getting removed prematurely from 
Ubuntu prior to removal from Debian, so I'm getting a little 
trigger-happy, hence my email.


Again, apologies for jumping the gun here. :)
Erich

On 2/17/2024 4:22 PM, Erich Eickmeyer wrote:
Ardour 8.3 has been released and no longer depends on deprecated GTK2 
as a modified version is bundled within. 
https://ardour.org/whatsnew83.html


Considering ardour has been scheduled for autoremoval on 06 March 
(#1061203), I highly recommend getting this updated as soon as 
possible to avoid this removal. Since the library is now bundled, the 
dependency on libgtk2.0-dev can be dropped.


Thanks,
Erich
--
Erich Eickmeyer
Ubuntu MOTU
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu







OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Ardour 8.4 has been released and no longer depends on deprecated GTK2
https://ardour.org/whatsnew.html

Please consider updating Ardour before the autoremoval is triggered.

Thanks,

--
robin - ardour.org

On 2024-02-18 01:43, Erich Eickmeyer wrote:
Apologies, this has *not* been released yet, but will hopefully be 
released in the next week, so please keep an eye on uscan.


Regardless, when it does get released, I will likely send out another 
email. Additionally, packages have been getting removed prematurely from 
Ubuntu prior to removal from Debian, so I'm getting a little 
trigger-happy, hence my email.


Again, apologies for jumping the gun here. :)
Erich

On 2/17/2024 4:22 PM, Erich Eickmeyer wrote:
Ardour 8.3 has been released and no longer depends on deprecated GTK2 
as a modified version is bundled within. 
https://ardour.org/whatsnew83.html


Considering ardour has been scheduled for autoremoval on 06 March 
(#1061203), I highly recommend getting this updated as soon as 
possible to avoid this removal. Since the library is now bundled, the 
dependency on libgtk2.0-dev can be dropped.


Thanks,
Erich
--
Erich Eickmeyer
Ubuntu MOTU
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu







OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061203: Ardour - GTK2 removal

[Robin Gareus]

Upcoming Ardour 8.3 no longer depends on GTK[mm]2.4.
It still depends on glibmm-2.4 (>=2.32.0) which is available in trixie.

We hope to release Ardour 8.3 (https://git.ardour.org/ardour/ardour) 
sometime mid February 2023, and it would be nice if DDs could check 
feasibility of packaging it beforehand.


see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967257


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061203: Ardour - GTK2 removal

[Robin Gareus]

Upcoming Ardour 8.3 no longer depends on GTK[mm]2.4.
It still depends on glibmm-2.4 (>=2.32.0) which is available in trixie.

We hope to release Ardour 8.3 (https://git.ardour.org/ardour/ardour) 
sometime mid February 2023, and it would be nice if DDs could check 
feasibility of packaging it beforehand.


see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967257


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Upcoming Ardour 8.3 no longer depends on GTK2.

Current Ardour/git (8.2-34-g4f5a801209) already dropped the dependency.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

Upcoming Ardour 8.3 no longer depends on GTK2.

Current Ardour/git (8.2-34-g4f5a801209) already dropped the dependency.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

On Mon, 6 Nov 2023 14:26:51 +0100 Bastian Germann  wrote:

Control: tags -1 wontfix

Upstream does not want to move to another toolkit, so when GTK 2 is
removed, ardour has to go as well.



For Arch, upstream considers copying relevant gtk/mm libraries into 
Ardour's source tree. Would that work for Debian as well?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#967257: ardour: depends on deprecated GTK 2

[Robin Gareus]

On Mon, 6 Nov 2023 14:26:51 +0100 Bastian Germann  wrote:

Control: tags -1 wontfix

Upstream does not want to move to another toolkit, so when GTK 2 is
removed, ardour has to go as well.



For Arch, upstream considers copying relevant gtk/mm libraries into 
Ardour's source tree. Would that work for Debian as well?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054233: LV2 plugin install path

[Robin Gareus]

The LV2 FHS that Jeremy mention can be found at
https://lv2plug.in/pages/filesystem-hierarchy-standard.html

Now you may not like, or disagree with the official standard, but 
breaking it is not acceptable. This affects various 3rd party software, 
notably Reaper, Harrison Mixbus, Ardour and other non-free DAWs that 
expect LV2 plugins in /usr/lib/lv2/


LV2s are to be installed $PREFIX/lib/lv2 (unrelated to $LIBDIR).
Most LV2 plugin build systems use LV2DIR = $PREFIX/lib/lv2 for this.

Thanks in advance,
robin

PS. VST3 has a similar spec using /usr/lib/vst3/ - 
https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054233: LV2 plugin install path

[Robin Gareus]

The LV2 FHS that Jeremy mention can be found at
https://lv2plug.in/pages/filesystem-hierarchy-standard.html

Now you may not like, or disagree with the official standard, but 
breaking it is not acceptable. This affects various 3rd party software, 
notably Reaper, Harrison Mixbus, Ardour and other non-free DAWs that 
expect LV2 plugins in /usr/lib/lv2/


LV2s are to be installed $PREFIX/lib/lv2 (unrelated to $LIBDIR).
Most LV2 plugin build systems use LV2DIR = $PREFIX/lib/lv2 for this.

Thanks in advance,
robin

PS. VST3 has a similar spec using /usr/lib/vst3/ - 
https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentation/Locations+Format/Plugin+Locations.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

[Robin Gareus]

Hello fellow Debian users,

I wish I had better news for you but at this point in time PipeWire is 
not a replacement for JACK when it comes to pro-audio. Neither in terms 
of reliability, performance or features. It is certainly not something 
to use in a studio with paying customers, or live on stage.


There are still regular issues [1] coming up, configuration is still not 
easily accessible [2], freewheeling does not always work, and 
performance when using many clients is not yet equal to how JACK handles 
context-switches.


JACK is mature and reliable, musicians can trust it live on stage, 
pipewire is still under heavy development and sadly not yet ready for 
prime-time.


On the upside JACK and pipewire can co-exist. When jackd requests a 
device via d-bus, pipewire does (or should) release it.


At this point it is even unclear if JACK will be ever be discontinued. A 
recent discussion at [3] investigates the possibility to run pipewire on 
top of JACK, but that is a different story.


--
robin

PS. I have been involved with development of both JACK, design of 
PipeWire and am developing pro-audio software such as Ardour (I am also 
a Debian user since Potato).


[1] https://discourse.ardour.org/t/ardour-inputs-with-pipewire/108489
[2] 
https://discourse.ardour.org/t/how-does-pipewire-perform-with-ardour/107381/12
[3] 
https://lists.linuxaudio.org/hyperkitty/list/linux-audio-...@lists.linuxaudio.org/thread/I3BSVFO6DU7S2L7ATA7WOSDS7BTS4BPH/



On Sat, 15 Jan 2022 17:14:16 + =?utf-8?Q?Cr=C3=A1udio?= 
 wrote:

Hi Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attention!Hi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments... Thank you for your attention!Hi 
Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attentioHi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments...

Thank you for your attention!

Cláudio.

‐‐‐ Original Message ‐‐‐
Em quinta-feira, 30 de dezembro de 2021 às 14:03, chris 
 escreveu:

> `pipewire` is providing its own replacement for `jack`, so if you are using 
`pipewire` maybe you should not have `jackd2` installed at all.
>
> I think I've done exactly the following:
>
> ```
>
> aptitude --schedule-only install libspa-0.2-jack qsynth rosegarden; aptitude 
--schedule-only full-upgrade; aptitude install
>
> aptitude purge pulseaudio pulseaudio-module-bluetooth 
pulseaudio-module-gsettings
>
> aptitude purge qjackctl jackd jackd2
> ```
>
> Then, to start an app needing `jack`, I did:
>
> `pw-jack qsynth` (don't forget to add a soundfont in `settups/soudfounts`)
>
> then:
>
> `rosegarden 28316.mid` (you must go in `studio/manage midi devices` and 
select a mdi output)
>
> And it worked.
>
> I'm using unstable.
>
> Right after switching to pipewire, I did:
>
> ```
>
> aptitude install libspa-0.2-bluetooth pipewire-audio-client-libraries
> aptitude purge pipewire-media-session
> aptitude reinstall wireplumber
> ```
>
> Maybe as a user you should do:
>
> ```
>
> systemctl --user --now disable pulseaudio.service pulseaudio.socket
>
> systemctl --user mask pulseaudio
>
> systemctl --user restart pipewire
> ```
>
> Maybe there should be a dependency conflict between `pipewire `and `jackd`?
>
> Also, concerning
>
> https://wiki.debian.org/PipeWire#For_JACK";>
>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

[Robin Gareus]

Hello fellow Debian users,

I wish I had better news for you but at this point in time PipeWire is 
not a replacement for JACK when it comes to pro-audio. Neither in terms 
of reliability, performance or features. It is certainly not something 
to use in a studio with paying customers, or live on stage.


There are still regular issues [1] coming up, configuration is still not 
easily accessible [2], freewheeling does not always work, and 
performance when using many clients is not yet equal to how JACK handles 
context-switches.


JACK is mature and reliable, musicians can trust it live on stage, 
pipewire is still under heavy development and sadly not yet ready for 
prime-time.


On the upside JACK and pipewire can co-exist. When jackd requests a 
device via d-bus, pipewire does (or should) release it.


At this point it is even unclear if JACK will be ever be discontinued. A 
recent discussion at [3] investigates the possibility to run pipewire on 
top of JACK, but that is a different story.


--
robin

PS. I have been involved with development of both JACK, design of 
PipeWire and am developing pro-audio software such as Ardour (I am also 
a Debian user since Potato).


[1] https://discourse.ardour.org/t/ardour-inputs-with-pipewire/108489
[2] 
https://discourse.ardour.org/t/how-does-pipewire-perform-with-ardour/107381/12
[3] 
https://lists.linuxaudio.org/hyperkitty/list/linux-audio-...@lists.linuxaudio.org/thread/I3BSVFO6DU7S2L7ATA7WOSDS7BTS4BPH/



On Sat, 15 Jan 2022 17:14:16 + =?utf-8?Q?Cr=C3=A1udio?= 
 wrote:

Hi Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attention!Hi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments... Thank you for your attention!Hi 
Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attentioHi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments...

Thank you for your attention!

Cláudio.

‐‐‐ Original Message ‐‐‐
Em quinta-feira, 30 de dezembro de 2021 às 14:03, chris 
 escreveu:

> `pipewire` is providing its own replacement for `jack`, so if you are using 
`pipewire` maybe you should not have `jackd2` installed at all.
>
> I think I've done exactly the following:
>
> ```
>
> aptitude --schedule-only install libspa-0.2-jack qsynth rosegarden; aptitude 
--schedule-only full-upgrade; aptitude install
>
> aptitude purge pulseaudio pulseaudio-module-bluetooth 
pulseaudio-module-gsettings
>
> aptitude purge qjackctl jackd jackd2
> ```
>
> Then, to start an app needing `jack`, I did:
>
> `pw-jack qsynth` (don't forget to add a soundfont in `settups/soudfounts`)
>
> then:
>
> `rosegarden 28316.mid` (you must go in `studio/manage midi devices` and 
select a mdi output)
>
> And it worked.
>
> I'm using unstable.
>
> Right after switching to pipewire, I did:
>
> ```
>
> aptitude install libspa-0.2-bluetooth pipewire-audio-client-libraries
> aptitude purge pipewire-media-session
> aptitude reinstall wireplumber
> ```
>
> Maybe as a user you should do:
>
> ```
>
> systemctl --user --now disable pulseaudio.service pulseaudio.socket
>
> systemctl --user mask pulseaudio
>
> systemctl --user restart pipewire
> ```
>
> Maybe there should be a dependency conflict between `pipewire `and `jackd`?
>
> Also, concerning
>
> https://wiki.debian.org/PipeWire#For_JACK";>
>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

[Robin Gareus]

Hello fellow Debian users,

I wish I had better news for you but at this point in time PipeWire is 
not a replacement for JACK when it comes to pro-audio. Neither in terms 
of reliability, performance or features. It is certainly not something 
to use in a studio with paying customers, or live on stage.


There are still regular issues [1] coming up, configuration is still not 
easily accessible [2], freewheeling does not always work, and 
performance when using many clients is not yet equal to how JACK handles 
context-switches.


JACK is mature and reliable, musicians can trust it live on stage, 
pipewire is still under heavy development and sadly not yet ready for 
prime-time.


On the upside JACK and pipewire can co-exist. When jackd requests a 
device via d-bus, pipewire does (or should) release it.


At this point it is even unclear if JACK will be ever be discontinued. A 
recent discussion at [3] investigates the possibility to run pipewire on 
top of JACK, but that is a different story.


--
robin

PS. I have been involved with development of both JACK, design of 
PipeWire and am developing pro-audio software such as Ardour (I am also 
a Debian user since Potato).


[1] https://discourse.ardour.org/t/ardour-inputs-with-pipewire/108489
[2] 
https://discourse.ardour.org/t/how-does-pipewire-perform-with-ardour/107381/12
[3] 
https://lists.linuxaudio.org/hyperkitty/list/linux-audio-...@lists.linuxaudio.org/thread/I3BSVFO6DU7S2L7ATA7WOSDS7BTS4BPH/



On Sat, 15 Jan 2022 17:14:16 + =?utf-8?Q?Cr=C3=A1udio?= 
 wrote:

Hi Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attention!Hi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments... Thank you for your attention!Hi 
Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attentioHi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments...

Thank you for your attention!

Cláudio.

‐‐‐ Original Message ‐‐‐
Em quinta-feira, 30 de dezembro de 2021 às 14:03, chris 
 escreveu:

> `pipewire` is providing its own replacement for `jack`, so if you are using 
`pipewire` maybe you should not have `jackd2` installed at all.
>
> I think I've done exactly the following:
>
> ```
>
> aptitude --schedule-only install libspa-0.2-jack qsynth rosegarden; aptitude 
--schedule-only full-upgrade; aptitude install
>
> aptitude purge pulseaudio pulseaudio-module-bluetooth 
pulseaudio-module-gsettings
>
> aptitude purge qjackctl jackd jackd2
> ```
>
> Then, to start an app needing `jack`, I did:
>
> `pw-jack qsynth` (don't forget to add a soundfont in `settups/soudfounts`)
>
> then:
>
> `rosegarden 28316.mid` (you must go in `studio/manage midi devices` and 
select a mdi output)
>
> And it worked.
>
> I'm using unstable.
>
> Right after switching to pipewire, I did:
>
> ```
>
> aptitude install libspa-0.2-bluetooth pipewire-audio-client-libraries
> aptitude purge pipewire-media-session
> aptitude reinstall wireplumber
> ```
>
> Maybe as a user you should do:
>
> ```
>
> systemctl --user --now disable pulseaudio.service pulseaudio.socket
>
> systemctl --user mask pulseaudio
>
> systemctl --user restart pipewire
> ```
>
> Maybe there should be a dependency conflict between `pipewire `and `jackd`?
>
> Also, concerning
>
> https://wiki.debian.org/PipeWire#For_JACK";>
>


OpenPGP_signature
Description: OpenPGP digital signature

Re: [Faudiostream-users] How to place values in lists?

[Robin Gareus]

On 8/20/22 00:23, Albert Graef wrote:
> On Fri, Aug 19, 2022 at 6:23 PM Yann Orlarey  wrote:
> 
>> We will never thank Albert Graef enough for the black magic of pattern
>> matching in Faust ;-)
>>
> 
> Thanks! So even though nobody uses Pure much these days (including myself),
> its pattern-matching code will survive in Faust. ;-)
> 
> I was about to chime in to help resolve Robin's troubles making his design
> generic, but you beat me to it!
> 
Hi Albert,

thank you for faust2lv2! It is my favorite target.

Cheers!
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] How to place values in lists?

[Robin Gareus]

On 8/19/22 08:19, Yann Orlarey wrote:
> Hi Robin,
> 
> Here is a generic shelfcascade with an arbitrary list of frequencies. The
> gains are directly routed. They are in the reverse order (the first input
> is the gain of the last stage).
> 
> 
> shelfcascade(lf) = bus(lf), ls3(first(lf)) : sc(lf) // lf : list of
> frequencies
> with {
> sc((f1, f2, lf)) = bus((f2,lf)), bs3(f1,f2) : sc((f2,lf)); // recursive
> pattern
> sc((f1, f2)) = _, bs3(f1,f2) : hs3(f2); // halting pattern
> bus(l) = par(i, outputs(l), _); // a bus of the size of a list
> first((x,xs)) = x; // first element of a list
> };
> 

Hello Yann,

Wow. Now that is a brilliant solution, and I have learned a few nice new
tricks there as well. Splicing the frequency list for the halting
pattern is something I would never have thought to do. I was too focused
on using an iterator.

Is there a reason why you have used outputs(l) instead of ba.count(l)?

Thank you!

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] How to place values in lists?

[Robin Gareus]

On 8/19/22 00:24, b...@magnetophon.nl wrote:
> Hi Robin,
> 
> When I saw your shelving based MB compressor, I also set out to make a
> generic N band and M channel version of it.  :)
> I ran into the same problem, and came up with this solution:
> https://github.com/magnetophon/faustExperiments/blob/shelfComp/N_band_Compressor_N_chan.dsp#L47
> 

Hello Bart,

For the analysis stage using HP/LP you can run the filters in parallel,
like you do in line 68-73. However when applying the gain to each band
using a shelving filter, like I'd like to, it has to be done in sequence.

> Is your WIP also online already?

It is still the same that I have linked to earlier. - I have mostly
given up on providing a generic method, and actually believe that it is
impossible with FAUST at this point in time. But it is trivial to use
any number of bands by just writing it out, and you don't change the
[max] number of bands dynamically anyway.

Realistically a four band version is more than sufficient when mixing or
mastering. For Klaus' project where there's no human operator to set the
frequencies by ear, an eight band split may be preferable.

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] How to place values in lists?

[Robin Gareus]

On 8/17/22 22:12, Hermann Meyer wrote:
> 
> were you could put anything you like into the filterbank, when defined,
> while set frequency at runtime.
>
> process= _: geq: ( dist5s , dist4s , dist3s, dist2s, dist1s)

Thanks for the confirmation that what I'm currently doing is not far off
the beaten track. Similar concepts are also in filters.lib.


The actual use-case is to directly "pipe" the output of the analyzer
into a custom filter-stage:

```
  _ :< bus(2) : (an.analyzer (6, freqs), _) : filters (freqs);
```

This works with for a **fixed** number of N bands, which defines the
number of gain parameters as M = N+1:

```
  filters(fq, g1, g2, g3,..,gM) = _;
```

I would however prefer a generic implementation, that works for any
number of N > 0 bands, as explained at
https://gist.github.com/x42/eeb2aa9f9cc4a9083fb2cf2d86645c9a#file-mcomp-dsp-L43-L54

I'm not sure if this is possible in FAUST. But since it is trivial in
C/C++ it probably is and I just don't see it.

Cheers!

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [Faudiostream-users] How to place values in lists?

[Robin Gareus]

Hi Klaus,

Thanks for the reply. If I understand correctly, waveform is a read-only
primitive, and only work for constant data. Am I missing something? Do
you have an example?

I suppose a rwtable could be abused as intermediate. But it seems like
overkill, for just getting arguments from a function call stack.

--
robin

On 8/17/22 18:55, Klaus Scheuermann wrote:
> I did a list with wavform once
> https://faustdoc.grame.fr/manual/syntax/#waveform-primitive
> 
> Hope it helps...
> 
>> On 17. Aug 2022, at 18:10, Robin Gareus  wrote:
>>
>> Hello Faust community,
>>
>> I'm brushing up my FAUST skills. It's been over a decade and it's
>> amazing to see how far things have grown. Well now, I just ran into an
>> issue:
>>
>>
>> How can I place signal primitive into a list?
>>
>> e.g. use  _,_  as list arguments (_,_) for `an.analyzer(3, HERE)`
>>
>>
>> If I understand correctly, lists are just parallel composition. So I
>> expected an extra pair of brackets to work. Why doesn't it?
>>
>>
>> -8<-
>>
>> Perhaps the deeper issue is the design-pattern that I'm aiming for. So
>> let me elaborate. The specific use-case is a multiband effect[1]:
>>
>> The following works (implementation omitted for readability):
>>
>> ```
>> apply(fq,g1,g2,g3,g4) = _;
>>
>> freqs=100,200,300;
>>
>> process= _ <: par(i,2,_)
>>   : (an.analyzer(6, (freqs)) , _)
>>   : apply (freqs);
>>
>> ```
>>
>> Now, I'd like to make this generic for arbitrary numbers of frequency
>> bands, rather than 3 hardcoded band-splits. This is similar how
>> an.analyzer() or filterbank work, except with an additional gain
>> parameter for each band:
>>
>>
>> ```
>> nuapply(freqs, gain) = _
>>  with {
>>nb   = ba.count(freqs);
>>f(n) = ba.take(n, freqs);
>>g(n) = ba.take(n, gain); // bm +1 elemements
>>  };
>> ```
>>
>> So far so good. This works with explicit literal arguments.
>>
>> However I fails to see how the output of analysis stage can be passed as
>> list.
>>
>> I tried another approach using `nu2apply(freqs)` and then
>> selectn() the gain levels from input bus, but that quickly becomes a mess.
>>
>> What is the Faustian way to implement this?
>>
>> Thanks in advance,
>> robin
>>
>> --
>>
>> [1]
>> https://gist.github.com/x42/eeb2aa9f9cc4a9083fb2cf2d86645c9a#file-mcomp-dsp-L43-L60
>> ___
>> Faudiostream-users mailing list
>> Faudiostream-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> 



OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

[Faudiostream-users] How to place values in lists?

[Robin Gareus]

Hello Faust community,

I'm brushing up my FAUST skills. It's been over a decade and it's
amazing to see how far things have grown. Well now, I just ran into an
issue:


How can I place signal primitive into a list?

e.g. use  _,_  as list arguments (_,_) for `an.analyzer(3, HERE)`


If I understand correctly, lists are just parallel composition. So I
expected an extra pair of brackets to work. Why doesn't it?


-8<-

Perhaps the deeper issue is the design-pattern that I'm aiming for. So
let me elaborate. The specific use-case is a multiband effect[1]:

The following works (implementation omitted for readability):

```
apply(fq,g1,g2,g3,g4) = _;

freqs=100,200,300;

process= _ <: par(i,2,_)
   : (an.analyzer(6, (freqs)) , _)
   : apply (freqs);

```

Now, I'd like to make this generic for arbitrary numbers of frequency
bands, rather than 3 hardcoded band-splits. This is similar how
an.analyzer() or filterbank work, except with an additional gain
parameter for each band:


```
nuapply(freqs, gain) = _
  with {
nb   = ba.count(freqs);
f(n) = ba.take(n, freqs);
g(n) = ba.take(n, gain); // bm +1 elemements
  };
```

So far so good. This works with explicit literal arguments.

However I fails to see how the output of analysis stage can be passed as
list.

I tried another approach using `nu2apply(freqs)` and then
selectn() the gain levels from input bus, but that quickly becomes a mess.

What is the Faustian way to implement this?

Thanks in advance,
robin

--

[1]
https://gist.github.com/x42/eeb2aa9f9cc4a9083fb2cf2d86645c9a#file-mcomp-dsp-L43-L60


OpenPGP_signature
Description: OpenPGP digital signature
___
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released

[Robin Gareus]

On 7/28/22 15:52, Chris Cannam wrote:
> 
> The version in the .pc file is written in at install time,

Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version:
1.8.2 for rubberband v3.0.0

the .pc.in file likely needs a placeholder %VERSION% so that it is
replaced at install time.

> The ABI has been at 2.something since version 1.2, 

Yeah that's fine. I was just surprised to see the age being zero.

http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Rubber Band Library v3.0.0 released

[Robin Gareus]

On 7/14/22 21:20, Chris Cannam wrote:
> Version 3.0.0 of Rubber Band Library is now available.
> 
> https://breakfastquay.com/rubberband/
>

Congrats on the release and thanks for the very informative blog post.

One small question:

https://hg.sr.ht/~breakfastquay/rubberband/browse/rubberband.pc.in?rev=v3.0.0

states Version: 1.8.2 (not 3.0.0).
The ABI version of the shared object is 2.2.0

Is that expected?

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Linuxaudio.org update and next steps--call for community input and participation

[Robin Gareus]

Dear Linux Audio enthusiasts,

As you may have seen on
https://lists.linuxaudio.org/archives/linux-audio-announce/2022-July/003054.html
our long time Director wishes to  step down from his duties.

Discussion continues on the
https://lists.linuxaudio.org/listinfo/consortium email list. The list
archive is open to the public, and everyone who is interested is very
welcome to join the discussion there.

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?

[Robin Gareus]

On 5/19/22 22:27, Fons Adriaensen wrote:
> Don't know about Apple. Last time I looked it didn't have clock_gettime(),

While there is a corresponding mach/clock.h, for the case at hand it is
preferable to use Apple's Core Audio, CoreMIDI. MIDI Event scheduling is
abstracted, and there is dedicated API to convert timestamped events
with high precision:

AudioConvertNanosToHostTime() and AudioConvertHostTimeToNanos()

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Any csound experts here ?

[Robin Gareus]

On 2/1/22 12:53, Fons Adriaensen wrote:
> Hello all,

Hi Fons,

I'm not a csound expert, but I do know the answer to at least 2 of your
questions:

> * run Csound with Jack,

  -+rtaudio=jack

> * using Ninp input ports and Nout output ports,

I don't recall this being a parameter, but the `outch`  and `nchnls`
opcodes sets the number of output channels. I never tried this myself
with more than 2 channels though.

> * not autoconnecting any ports,

 -odac:null and -iadc:null

--
robin


OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Programming LV2 plugin from scratch tutorial video series

[Robin Gareus]

On 10/18/21 10:54 PM, Fons Adriaensen wrote:

> I never got to grips with turtle. 

https://www.w3.org/TR/turtle/ to the rescue :)

There is currently ongoing work to allow JSON-LD as alternative, but
that's just the encoding.

> In particular not with things like:

> @prefix doap:   .
> @prefix lv2:    .
> @prefix rdf:    .
> @prefix rdfs:   .
> @prefix units:  .
> 
> All docs and tutorials I found mention that the URLs do NOT
> mean that an application reading a file that contains them
> would actually need to read them from the web (which would
> be a unacceptable security risk anyway).

URIs are just used as unique identifiers. They do not even need to
resolve and one can use urn: as well. However in most cases they point
to online documentation which is helpful to developers.

> Which raises the question why those @prefix lines are 
> required at all. 

@prefix just syntactic sugar, so you do not have to spell out the full
URI every time. Instead of e.g.
  http://lv2plug.in/ns/lv2core#ControlPort
you can just write
  lv2:ControlPort

> So all that these lines seem to provide is some illusion
> of conformity which isn't enforced or checked at all. 

Those URIs are defined in header files of the LV2 ontology and must
match, otherwise a LV2 plugin does not conform to the spec. There are
tools like lv2lint to check the validity, but other than that, they are
just unique IDs.

> So the conclusion is that this isn't any better than any
> ad-hoc way of encoding the plugin metadata.

Except it is not ad-hoc, but a w3c standard. Why invent an new meta-data
schema for unique resource IDs, when there is already a very good one
out there, that is also formalized as RFC?

As side-effect you can also use existing tools from the semantic web to
index and search LV2 plugins. IIRC the MOD website uses that.

I hope that clarifies things,
robin




OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Phase rotation

[Robin Gareus]

To follow up, there is

https://github.com/x42/phaserotate.lv2#readme

Binaries of the plugins are available from
https://x42-plugins.com/x42/x42-phaserotate
The commandline tool is currently only available when building from source.

On 8/31/21 3:09 PM, Fons Adriaensen wrote:
> On Tue, Aug 31, 2021 at 04:24:43AM +0200, Robin Gareus wrote:
>  
>>> Now don't believe that phase shifting a signal will always result
>>> in a waveform with a lower peak/RMS ratio. It could very well
>>> have the opposite effect.
>>
>> Well, there is a minimum. So far I just brute force detect it, trying
>> all angles in 1 deg steps on a file.
> 
> Brute force indeed...

Works sufficiently well and fast, I have a few ideas how to integrate it
into the plugins, but it is tricky since it requires context.

> In other words, this really kills whatever snappy transient response
> you may have had.
I did some listening tests, both on individual samples as well as using
the plugin on the master-bus with various performances. In many cases it
is audibly transparent.

But yes, it can kill quality, just like [multiband] compressors,
limiters, or any tool, really.

On the upside I now have better understanding of segmented convolution,
hilbert filter and related FFT topics, which is what this exercise was
about.

Cheers!
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Phase rotation

[Robin Gareus]

Hi Fons,

Thanks for the reply, and from vacation no less.

On 8/30/21 7:06 PM, Fons Adriaensen wrote:

> To implement this you need more than just FFT and IFFT. Using only
> those on each block would amount to circular convolution, while
> what you need is linear convolution. Changing only the phase of
> a signal is just a special case of filtering, which means the output
> will be longer than the input.

Aha! That is what I was missing and didn't understand. Thank you.

> Define the phase shift in the
> frequency domain (i.e. as if it were the result of an FFT), do the
> inverse FFT and use the result as the IR for the convolver.

So just compute a FIR and apply it. I now have a working prototype.

I hoped to sidestep that because the phase-angle should be a sweepable
parameter. I can probably make this work by cross-fading the computed
FIR when the parameter changes.

> Now don't believe that phase shifting a signal will always result
> in a waveform with a lower peak/RMS ratio. It could very well
> have the opposite effect.

Well, there is a minimum. So far I just brute force detect it, trying
all angles in 1 deg steps on a file.

Finding out if it can be computed is up next. Perhaps using linear
regression on the spectrum of the file. I may pick your brain again when
I progress to that stage.
> Greetings to all from sunny Crete.

The next retsina is on me, unless you prefer a cold ΑΛΦΑ beer :)

Stay safe!
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Phase rotation

[Robin Gareus]

Hi all,

During the last days, I looked into phase-ration: components of a signal
are delayed differently depending on their frequency.

A good write up on the subject can be found at [1], and a commercial
tool is available from [2].

The interesting aspect is that phase rotation does not alter the sound
of the signal nor the loudness. However changing the phase vs. frequency
relationship between lower and upper harmonics changes the waveform and
can affect where the digital peak occurs.

For this reason phase rotation is commonly used by radio stations to
reduce the signal peak, and make the signal more symmetrical. Phase
rotation circuits are also used during mastering to increase headroom.

To implementing this, the following operations are performed:

* FFT
* rotate phase, retain magnitude
* inverse FFT

This works well, except for the first FFT bin: 0 Hz, DC offset. If the
phase-shift changes the average DC level of the signal there is a
discontinuity.

I could use some of the collective expertise of this list.

Has anyone looked into this before?

Is it even possible with piecewise block processing?

Is there a way to calculate the DC offset?

Since the overall magnitude does not change simply summing up the bins
results in the same 0th bin. I considered to low-pass filter the DC
offset, or simply remove the DC offset using a high-pass before the FFT
to mitigate the issue. But either introduces different artifacts. If I
understand correctly, a Hilbert transform as mentioned at [1] has the
same issue.

I've condensed the DSP into a simple test tool to toy around with the
issue: https://gist.github.com/17fd61b04d4c4939727dfdccd79f53a5

with low frequencies, the differences are obvious:

* https://i2.paste.pics/cc32f6c5d622e31ab0e830ab1ce205e9.png (2.5 *
FFT's base-freq)
* https://i2.paste.pics/3e6eb827148b90800569843c11da2e48.png (0.37 *
FFT's base-freq)


I'd appreciate any insights.

--
robin


[1]
https://forum.juce.com/t/how-to-rotate-the-phase-of-an-audio-signal/39072/10

[2] https://www.izotope.com/en/products/rx/features/phase.html



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/7/21 1:00 PM, Wim Taymans wrote:
> This utterly fails with jackd on this system, it doesn't even want
> to start all the clients, I'm sure it's something with the config somewhere...

jack has a port-limit (IIRC 256 by default). It is not dynamic and
unbound for performance reasons.

try:  jackd --port-max 1024 -d alsa ...

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/4/21 6:35 PM, John Murphy wrote:
> On Wed, 30 Jun 2021 15:48:31 -0700 Yuri wrote:
> [...]
>> Does anybody have experience using it?
>>
>> https://pipewire.org/
> 
> Yes. I've used it for a whole day now, on Linux Mint 20.1 Ulyssa base
> (Ubuntu 20.04 focal). Everything seems to just work.


Yes, the project is making huge progress. Also thanks to the many early
adopters filing helpful issue reports. Wim and his team address them at
incredible speed.

If you use it, be prepared to live on the bleeding edge, e.g. until last
week pipewire didn't set realtime permissions correctly, and the week
before had a crashing bug with Ardour querying ports when 3rd party apps
are involved. Fixed now.

So update early, update often

--
robin



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Robin Gareus]

On 7/1/21 12:48 AM, Yuri wrote:
> Somebody said on GitHub that "Pipewire is the soon to be successor to
> Jack/Pulseaudio".


Yes, and ALSA as well to some extent. To applications pipewire looks
like a running JACK server, or pulseaudio or like an ALSA device. So
existing apps do not have to be changed.

Search this list archives from 2018. There was a discussion of the
framework.

> Is Pipewire viewed like this by the wider community? Does anybody have
> experience using it?
> 

Yes, all Fedora 34 users, and some Arch'ers too. It comes up regularly
on the Ardour forum in recent months, top 3: [1,2,3].

There are still a few rough edges, but it matures quickly.

--
robin

[1]
https://discourse.ardour.org/t/has-anyone-experimented-with-pipewire-yet/104933
[2]
https://discourse.ardour.org/t/solved-is-there-a-simple-definitive-answer-to-getting-pipewire-fedora-34-to-play-nice/106059
[3] https://discourse.ardour.org/t/god-save-pipewire/105691



OpenPGP_signature
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#990448: RFP: yabridge -- A modern and transparent way to use Windows VST2 and VST3 plugins on Linux

[Robin Gareus]

Package: wnpp
Severity: wishlist

* Package name: yabridge
  Version : 3.3.1
  Upstream Author : Robbert van der Helm
* URL : https://github.com/robbert-vdh/yabridge/
* License : GPL
  Programming Lang: C++
  Description : A modern and transparent way to use Windows VST2 and VST3 
plugins on Linux


Yet Another way to use Windows VST plugins on Linux. Yabridge seamlessly
supports using both 32-bit and 64-bit Windows VST2 and VST3 plugins in a
64-bit Linux VST host as if they were native VST2 and VST3 plugins, with
optional support for plugin groups to enable inter-plugin communication
for VST2 plugins and quick startup times.

---

Note: This multimedia package *Enhances* digital audio workstations and
sequencers that support VST plugins (e.g. ardour, qtractor, LMMS).

Bug#990448: RFP: yabridge -- A modern and transparent way to use Windows VST2 and VST3 plugins on Linux

[Robin Gareus]

Package: wnpp
Severity: wishlist

* Package name: yabridge
  Version : 3.3.1
  Upstream Author : Robbert van der Helm
* URL : https://github.com/robbert-vdh/yabridge/
* License : GPL
  Programming Lang: C++
  Description : A modern and transparent way to use Windows VST2 and VST3 
plugins on Linux


Yet Another way to use Windows VST plugins on Linux. Yabridge seamlessly
supports using both 32-bit and 64-bit Windows VST2 and VST3 plugins in a
64-bit Linux VST host as if they were native VST2 and VST3 plugins, with
optional support for plugin groups to enable inter-plugin communication
for VST2 plugins and quick startup times.

---

Note: This multimedia package *Enhances* digital audio workstations and
sequencers that support VST plugins (e.g. ardour, qtractor, LMMS).

Re: [LAD] Freenode #lad #lau

[Robin Gareus]

On 6/12/21 8:37 PM, Marc Groenewegen wrote:
> What happened? 

The channels moved to https://libera.chat/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is there an LV2 plugin that can add echo like echo added by large cathedrals?

[Robin Gareus]

On 4/6/21 10:00 PM, Yuri wrote:
> I remember listening to the talk of researchers who were traveling to
> different old cathedrals, particularly to Hagia Sophia in Turkey, and
> measuring echo in these cathedrals. Such buildings add a lot of deep and
> very prolonged echo which depends on the building's shape and materials.
> They were quantifying the noise response too.
>

You could ask CCRMA for the Hagia Sophia IRs.

Alternatively https://www.openair.hosted.york.ac.uk/?page_id=36 has a
few very nice ones.

St. Mary's Abbey has a very long reverb tail, as does the Hamilton
Mausoleum. Also check out the Spokane Woman's Club.

The Lady Chapel of the Ely cathedral is amazing, too:
https://www.jezwells.org/Computer_music_tools.html#Impulse_responses

> Are there LV2 plugins that can add same or similar echo as cathedrals add?

Any convolver will do. Apart from the ones that others have already
mentioned:

https://lsp-plug.in/ has a very efficient and reliable one with plenty
of controls. If you want a simple one with presets-only (incl. the
openairlib) check out: https://x42-plugins.com/x42/x42-zconvolver

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] XUiDesigner -> create LV2 plugs from scratch

[Robin Gareus]

Hi Fons,

On 3/23/21 9:59 PM, Fons Adriaensen wrote:
> If by that you mean it can't use dynamic libs, then how do
> you arrive at that conclusion ?

It is motivated by running plugins in process to avoid context switches.

Say you have 2 plugins, one using aubio.so.2 the other aubio.so.3, or
different plugins using different versions of libavresample.so

Distros often bundle multiple major versions of libraries and that is
fine as long as a given ABI of that library is only used by different
processes. But when you want to load plugins into a host, they will
conflict.

Another example where this happened in the past was fftw. Then this also
extends to various GUI toolkit conflicts (gtk 2/3/4 cannot co-exist in
the same memory space, nor can QT 4/5/6).

Plugins should be self-contained and not depend on external libs (except
for ones with a client/server interface where the lib needs to match the
server e.g. X11, openGL -- but those have versioned symbols and a stable
ABI).

As added benefit, this increases reliability when distributing plugin
binaries: The plugin does not use some random library version found on
the target system.


Cheers!
robin

References:
 https://ardour.org/plugins-in-process.html
 https://gist.github.com/abique/4c1b9b40f3413f0df1591d2a7c760db4
 https://linuxmusicians.com/viewtopic.php?p=84986#p84986
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] READ THIS IF YOU CARE ABOUT FREEDOM! Fwd: [LAA] Non DAW release including Non Session Manager (i.e. the real NSM)

[Robin Gareus]

On 1/29/21 6:18 PM, rosea.grammostola wrote:
> Linuxaudio community has a serious problem

Yes, the problem is that people here are not discussing Linux Audio
Development :)

"The Linux Audio Developers (LAD) list is dedicated to sound
architecture and application development for the Linux Operating
System." [1]

Please refrain from any personal references. Neither your nor J.Liles
messages are acceptable here. Please focus on technical aspects
pertaining to Linux/libre audio projects. Thank you.

PS. You may raise issues pertaining to policy [2] article 6 by
contacting the consortium [3].


[1] https://lists.linuxaudio.org/listinfo/linux-audio-dev
[2] http://linuxaudio.org/policy.html
[3] https://lists.linuxaudio.org/listinfo/consortium
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A question to plugin host devs

[Robin Gareus]

On 12/20/20 5:59 PM, Fons Adriaensen wrote:
> Hello all,
> 
> I wonder what are the pros and cons of using RTLD_NODELETE as
> a flag to dlopen() and call dlclose () as soon as the required
> symbols are loaded.
> 
> The alternative is to leave all shared object handles open until 
> the host terminates.

Why keep it around?

As soon as the last plugin instance is deleted from a session the
plugin's shared object can and should be unloaded. Otherwise you would
just accumulate [shared] memory simply by adding and removing different
plugins.

> What are you doing in your plugin host

VST3 and LV2 reference implementation for Linux just use RTLD_LAZY
(along with dlopen's default RTLD_LOCAL), and dlclose() when the last
instance is removed.

That is also what Ardour does for LV2 and VST3.

I do not know any plugin host that uses RTLD_NODELETE.
Besides, NODELETE is not portable. macOS' CFBundleLoadExecutable() and
Windows LoadLibraryExA do not have equivalent mechanism.

In the distant past, Ardour (really libsuil) used NODELETE for LV2 GUIs.
https://lv2plug.in/ns/extensions/ui#makeSONameResident
but that is no longer the case since the option was deprecated.

> (and why)

Accumulating memory generally degrades overall performance. The larger
the page table, the more expensive are context switches.

[Re]Loading the shared object adds overhead of static initialization,
which is usually done in the GUI thread and fast compared to any user
interaction. It's also a one time operation, not a periodic one.

As a side-effect it also aids plugin-developers. If a host unloads the
.so. A dev can recompile the plugin and reload it in the same session.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] wiki.linuxaudio.org mostly fixed again

[Robin Gareus]

On 3/15/20 1:26 AM, Jeremy Jongepier wrote:
> Dear all,
> 
> The linuxaudio.org wiki is almost fully functional again. 

Hi Jermey,

Thanks for your work so far!

It looks like most of the meta-data (JACK, LV2, ..) for apps is lost:

https://web.archive.org/web/20161119193236/http://wiki.linuxaudio.org/apps/daw_apps
vs https://wiki.linuxaudio.org/apps/daw_apps

and tag/categories don't work:

https://web.archive.org/web/20161129041747/http://wiki.linuxaudio.org/apps/categories/jack
 vs https://wiki.linuxaudio.org/apps/categories/jack

Also while rewriting works, dokuwiki isn't configured to 'userewrite'
and generates links using request parameters  doku.php?id=...

e.g. "Apps" in the left sidebar links to
 https://apps.linuxaudio.org/doku.php?id=apps:start
 instead of https://apps.linuxaudio.org/wiki/start

so long,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] BPM and key detection libraries

[Robin Gareus]

On 10/14/19 10:36 AM, Louigi Verona wrote:
> Hey everyone!
> 
> What are the bpm and key detection libraries people use for open source
> projects? And how good are they?

https://vamp-plugins.org/download.html are amazing.

You can test for yourself using sonic-visualizer.


Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Berlin Linux Audio meeting @ c-base 2019-10-08

[Robin Gareus]

On 10/7/19 9:18 PM, Daniel Swärd wrote:
> Hi all.
> 
> Tomorrow it's the scheduled meeting at c-base again. I don't know if
> I'll make it (I've stayed home from work today not feeling great), but
> maybe Louigi or Robin can gather people?

I'm sorry, but I won't be able to join this time, either.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

[Robin Gareus]

On 7/29/19 8:21 PM, Stephan Bourgeois wrote:

> Should meterbridge be maintained or should another metering app de bundled
> with jack?

Given that jack is cross-platform and meterbridge is a X11 application
it's not very likely to be bundled with jack itself.

The main use-case for meterbridge is the dpm mode with many channels to
check input activity.

You may also want to have a look at
https://lists.linuxaudio.org/archives/linux-audio-dev/2012-June/032475.html
- the debian package applied this, but it never reached upstream, it's
likely not relevant after your re-work either.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

[Robin Gareus]

On 7/29/19 8:21 PM, Stephan Bourgeois wrote:

> The only thing missing would be a 4x oversampling true peak meter.
https://github.com/x42/meters.lv2/ also comes with a jack app.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#916289: liblilv-0-0: Plugins in /usr/local/lib/lv2 are not scanned

[Robin Gareus]

On Wed, 12 Dec 2018 19:11:36 +0100 Julien ROGER 
wrote:
> Package: liblilv-0-0
> Version: 0.24.2~dfsg0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> LV2 plugins installed in /usr/local/lib/lv2 path are not visible in LV2 hosts.
> 
> lv2ls command doesn't show them either.
> 
> The problem comes from the "--default-lv2-path" option passed to the configure
> script (debian/rules commit 53a743c6).
> The specified path is "/usr/local/lv2" instead of "/usr/local/lib/lv2".
> 

Bump!

Please see http://lv2plug.in/pages/filesystem-hierarchy-standard.html

Just keeping the default should be fine:
   $HOME/.lv2:/usr/local/lib/lv2:/usr/lib/lv2

Note that the FHS specifies is "$PREFIX/lib/lv2" (not $LIBDIR/lv2).
LV2-plugins should not be installed in $(DEB_HOST_MULTIARCH) folders.

If I remember correctly "/usr/lib/$(DEB_HOST_MULTIARCH)/lv2" was added
in the past to transition wrongly packaged plugins.

Cheers!
robin

Bug#916289: liblilv-0-0: Plugins in /usr/local/lib/lv2 are not scanned

[Robin Gareus]

On Wed, 12 Dec 2018 19:11:36 +0100 Julien ROGER 
wrote:
> Package: liblilv-0-0
> Version: 0.24.2~dfsg0-2
> Severity: normal
> 
> Dear Maintainer,
> 
> LV2 plugins installed in /usr/local/lib/lv2 path are not visible in LV2 hosts.
> 
> lv2ls command doesn't show them either.
> 
> The problem comes from the "--default-lv2-path" option passed to the configure
> script (debian/rules commit 53a743c6).
> The specified path is "/usr/local/lv2" instead of "/usr/local/lib/lv2".
> 

Bump!

Please see http://lv2plug.in/pages/filesystem-hierarchy-standard.html

Just keeping the default should be fine:
   $HOME/.lv2:/usr/local/lib/lv2:/usr/lib/lv2

Note that the FHS specifies is "$PREFIX/lib/lv2" (not $LIBDIR/lv2).
LV2-plugins should not be installed in $(DEB_HOST_MULTIARCH) folders.

If I remember correctly "/usr/lib/$(DEB_HOST_MULTIARCH)/lv2" was added
in the past to transition wrongly packaged plugins.

Cheers!
robin

[LAD] LAC steaming to c-base, Berlin

[Robin Gareus]

Hi all,

A group of people who do not attend the Linux Audio Conference in
Stanford this year are meeting at c-base.org to participate remotely.

http://lac.linuxaudio.org/2019/#program

We'll watch the live-stream of the paper-presentations on Saturday,
Sunday, Monday 17h to 21h CET, and share dinner, which is sponsored by
the Paul Davis and the Ardour community!

You're very welcome to join our small local hallway track in the space
station below Berlin-Mitte, located in the 2nd backyard of Rungestraße
20, 10179 Berlin.

There'll also some un-conference BarCamp track, likley some LV2 hacking
on the week-end. Monday evening overlaps with the Bitwig user-group at
c-base. Going to be fun!

Looking forward to seeing you there,
robin

PS. Safe travels to all who head to Stanford.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Bit shift

[Robin Gareus]

On 3/17/19 5:56 PM, Jonathan Brickman wrote:
> That is likely to change depending on GCC optimization setting, no?

Not usually. It depends on the target architecture more than anything.

Even with -O0, gcc translates integer addition and multiplications into
a combination of bitwise and arithmetic operations if that is
appropriate for the target CPU.


On 3/12/19 11:43 PM, Will Godfrey wrote:
> Does anyone know if GCC will replace power of 2 
> multiplications/divisions of unsigned integers with bit shifts?
Not only power of two, and it depends. In some cases the compiler
doesn't replace it because the resulting code is not faster. Many modern
CPU already implement integer multiplication using bitwise operations in
microcode.

I don't know if this your question is academic, but if you plan to
manually optimize code, I highly recommend against that.

Write semantically! If you mean a multiplication, use (a * 2), if you
mean bit-shift use (a << 1). Do not use bitwise-operations when you
really do integer-arithmetics.

Your future self and code-contributers will thank you for it; as will
compilers targeting future CPU architectures.


2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [music-dsp] Sound Analysis

[Robin Gareus]

On 1/4/19 3:22 PM, Frank Sheeran wrote:
> Hey, if you don't want an actual Hammond, that's why I wrote the entire
> soft synth in the first place!  :-D
> 
> The main reason I'm doing this patch is as a case study showing my soft
> synth can emulate a real Hammond (and Leslie) warts and all, to a very deep
> level, and showing how one would go about it.

Hi Frank,

You may want to have a look at
   https://github.com/pantherb/setBfree
'warts and all' even managed to creep into the source-code there :)

The tonewheels in that case are pure sine waves with -40dB compartment
leakage, -40dB terminal-strip cross-talk and also -40dB for wire model,
but those are configurable (see src/tonegen.c). IMHO it does sound very
realistic e.g. https://vimeo.com/130633814

A related issue, there is a really nice paper analyzing the key-click:
https://asa.scitation.org/doi/full/10.1121/1.5003796

Cheers!
robin
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [LAD] So in 2019, which plugin "format"?

[Robin Gareus]

On 11/25/2018 11:47 PM, Gordonjcp wrote:
> Hi folks,
> 
> At the risk of igniting a flame war, if one were to develop softsynth
> plugins for Linux, what would be the "framework" of choice these days?

https://distrho.github.io/DPF/ -- https://github.com/DISTRHO/DPF

> Back in the day I wrote some using DSSI, which was a model I was pretty
> comfortable with.  I had a look at LV2 but couldn't work out how to
> generate the huge incomprehensible non-human-readable "ttl" files.

I thought you didn't want a flame-war? :)
How are they not human-readable? They're nice semantic triplets.

Anyway, you could use DPF to auto-generate the file for you.

> Where does the world stand now?

I don't know about 2019, but in 2018 LV2 still sucks least of the
available options.

In 2019, perhaps VST3 may become an alternative, but right now Bitwig is
the only Linux host to support it, and the VST-GUI API for Linux is also
still in flux.

ciao,
robin

PS. you could /steal/ some GPL code from e.g. zyn-fusion or helm.
The former uses DPF, the latter a patched JUCE to export LV2, both also
offer VST2 as alternative.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
> Thanks for going into this in such detail Robin. I never realised fp stuff
> could be *quite* so, umm, approximate!

Depending on context and the maths, the difference may not matter at
all, or may be off completely..

  float a = (1 + 1e20) - 1e20;
  float b = 1 + 1e20; b -= 1e20;
  printf ("%f %f\n", a, b);

Any guesses what this code prints without compiling it? :)

> I was using O3. Following on from this I found that if I removed either O3 or
> ffast-math the problem disappeared.

OK, so SSE/AVX/compiler-intrinsics are the issue at hand.

> It's quite possible that I'm over-thinking this as there are actually only a
> few iterations before the initial figures are re-calculated, but I don't like
> mysteries :(
> 

You could also disable this for a specific function only

__attribute__((optimize("-fno-fast-math")))
void different_mysteries_here (float val)
{
...
}

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/22/2018 09:27 PM, Hermann Meyer wrote:
> 
> 
> However, problems with NAN's and INF's when use -ffinite-math-only
> occurs only when we save preset values to file, and only sometimes then.

A shot in the dark..

Serializing a float in most parts of the world uses comma as decimal
separator. e.g. "0,5"

Reading this in the C-locale (dot as decimal separator) with c/c++
standard library functions returns 0. This may lead to a division by
zero later.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

Hi Will,

I just ran your code and -ffast-math does not make any difference.

With or without --ffast-math I get "int: 5 rem: 0.049994"

However optimizing the code with `-O2 --ffast-math` does make a
difference because SSE is used.

Do you also use -O2, or -O3 along with --fast-math?

On 11/22/2018 06:30 PM, Will Godfrey wrote:
[...]
> My suspicion is that the difference is due to accumulated rounding
> errors.
> 
> Curiously without the decrements the behavior with and without
> -ffast-math seems to be identical well into the millions.
Yep. you do loose precision. In IEEE 32bit float, there is no 0.1.

0.1 would be approximated as (13421773) * 2^(-27), and 0.05 as
(13421773) * 2^(-28) and truncated.

Note that this is an odd number. The last bit of the mantissa
(0x004d) is lost when the exponent changes.

A simpler example to show this is

#include 
#include 
int main (int argc, char** argv) {
  float a = 0;
  for (int i = 0; i < 100; ++i) {
a += 0.1f;
a -= 0.05f;
a = fmodf (a, 1.f);
  }
  printf ("%f\n", a);
  return 0;
}

using gcc 6.3.0-18+deb9u1, x86_64, this
prints 1.00 (when compiled with -O0)
and0.01 (when compiled with -O2 --fast-math)


The difference here is that the former calls fmodf(), while in the
latter, optimized, case the compiler uses cvtss2sd SSE instead. The
internal limits of float precision differ for those cases.


--ffast-math issues in audio-dsp are usually due to re-ordering and
reciprocal approximations. e.g. instead of (x / 2) the compiler calls
(0.5 * x), which can lead to different results if the inverse value does
not a precise floating point representation.  e.g.  1.0 / 0.1 != 10.0

A good read on the subject is
http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf (Goldberg,
David: "What Every Computer Scientist Should Know About Floating-Point
Arithmetic").

If you were change the two constants to
  a += 0.5f;
  a -= 0.25f;
the issue vanishes.

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Is -ffast-math safe for audio?

[Robin Gareus]

On 11/22/2018 07:28 PM, David Runge wrote:

> Rabbit hole stuff! SuperCollider came to a similar conclusion:
> https://github.com/supercollider/supercollider/issues/4116

This is a different issue. In SuperCollider's case they do want NaN and
not finite-math, that is not usually the case for audio.

If you have perform a calculation that can produce NaN or infinite
values or needs to distinguish +/-0 in your DSP code, there is a much
bigger issue.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Berlin Linux Audio meeting @ c-base 2018-11-06

[Robin Gareus]

On 11/04/2018 07:54 PM, Daniel Swärd wrote:
> Hi all.
> 
> Next meeting at c-base is on Tuesday 2018-11-06 at 20:00.

Wasn't it supposed to be the 2nd Tuesday every month?

My calender had it down on the 13th :(

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?

[Robin Gareus]

On 10/30/2018 09:36 AM, Hermann Meyer wrote:
> 
> Am 30.10.18 um 08:37 schrieb Hermann Meyer:
>>
>>
>> Am 29.10.18 um 15:34 schrieb Robin Gareus:
>>>> The plugins already loaded into memory should still hopefully be OK.
>>> yep.
>>>
>>> On Unix systems already loaded .so will be kept in memory. On Windows
>>> you cannot write/replace to a file that is currently opened.
>>>
>>> You can skip and postpone scanning of plugins that are currently in use
>>> until the next session load.
>>>
>>
>> During plugin development I check plugins usually (first) in jalv.

That's good advise.

>> Sometimes I forgot that I've loaded a plug already and update it,
>> result is always a crash in jalv.
>>
>> The same happen in Mixbus4, I've just checked it, out of curiosity.
>>

Ardour/Mixbus does no do as I suggested (it does not skip loaded
plugins). I mentioned it so that others don't make the same mistake.

> True, there is no problem when the update didn't happen in-place, means
> remove the older bundle and then install the new one ( like most package
> mangers does).
>  

In Ardour and jalv's implementation the LV2 world is constructed
statically at application start. Changes won't be picked up correctly.
It's different for VST

Also there may be conflicts by loading the plugin and later open a
mismatching GUI (different .so).


I usually think of changing or adding/removing plugins to be like adding
another [analog] stomp-box effect pedal between a guitar and amp. That
involves to re-plug cables. You don't usually do that while playing nor
while the amp is turned up.

the point is: I don't think it is important that the plugin-scanner must
be able to cope with changing plugins.

What would be nice though is to support scanning in background with a
priority list: When loading a session, first check the plugins that are
already in the session. block and wait until they're re-scanned.
Then load the session and continue plugin discovery in the background.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?

[Robin Gareus]

On 10/29/2018 06:52 AM, Tim wrote:

> On 10/29/2018 12:40 AM, Hermann Meyer wrote:
>> Downside of cached information is, that it could clash on plugin load
>> when the plugin have changed it's ports (updated).
If that happens you have a much bigger issue than stale caches.

Released plugins should not change ports or behavior in a way that is
not backwards compatible. Doing so would break existing sessions using
the plugin.


>> So when you save plugin information on your own, you need to check
>> before you at least load the plugin, if the cached information is
>> still valid.
>
> 
> Yes that was of great concern from the start of this effort.
> 
> Scenario 1: While the the program is not running, the user
>  installs, moves, removes, or upgrades a plugin, then runs
>  the program.
> I have an idea at program startup to compare the date/time
>  of each given plugin path with the one of the cache file.
> If different, reload the cache.

I suggest to prefer a checksum or hash (at least additionally), or use
inotify or some existing watch mechanism.

Ardour uses stat()'s mtime. There are various issues with this:
e.g. zip files do not include timezone, some tar archives include
strange timestamps, installers on other platforms do strange things, and
some users toy with clocks on occasion.
Edge cases like these have lead to countless headaches in the past.


> Scenario 2: While the the application is running - perhaps already
>  for hours into a project - the user decides to install, move, remove,
>  or upgrade a plugin. Watch out !
> I have an idea to 'watch' all the given plugin paths for changes
>  and take appropriate action: Crash ;-)
> I don't think the scenario is too drastic though.
> The plugins already loaded into memory should still hopefully be OK.

yep.

On Unix systems already loaded .so will be kept in memory. On Windows
you cannot write/replace to a file that is currently opened.

You can skip and postpone scanning of plugins that are currently in use
until the next session load.

> It might not be wise to alter my data or info of an already loaded
>  plugin if it is deleted or removed or upgraded, but at the very
>  very least I would like to be able to support loading a
>  'brand new' plugin if it suddenly appears.

Why? I've never seen someone installing/removing software while
recording or mixing. It also sounds like a bad idea to me.

What happens if you run two instances of the same DAW or two different
programs that share the plugin cache?

Do all programs watch for changes and use lock-files to prevent
concurrent scanning?

One solution is to ask a user to directly or indirectly initiate a scan.
Directly by pressing a button or indirectly by opening a session. These
actions are rarely performed concurrently.


> 
> Also IIUC sometimes plugin ports can be created on-the-fly? Ouch.
> 

Do you need to know the ports a-priori?

The host needs to load the plugin anyway to insert it. So the only
interesting part to cache is

 * Plugin-Name
 * Plugin-Author
 * Factory & User Presets
 * Category/Tags (if any)
 * Description (if any)

I/O and Control Ports are not usually something that's worth caching,
except perhaps for "has MIDI I/O" (to detect Instruments for plugins
that don't specify a category).

What other information are you interested to cache? Is there a benefit
to caching port names, default values, for each plugin?


> About my cache format: Since the highest denominator (most advanced)
>  in all these plugin types would be LV2, I think it would be really
>  cool if the Turtle tools or libraries could report ALL types
>  of plugins and generate new ttl files on the fly from found plugins.

RDF is generic, it can describe pretty much anything. I thought there is
already a LADPSA ontology. Also LADSPA uses RDF for presets.

TTL is just a RDF serialization. There is also some discussion to allow
JSON-LD as alternative to turtle for LV2.


LV2's ontology provides for a nice description of the basics, it really
uses  foaf[1] and doap[2,3] for the basics.  This leaves some
classification (categories, tags) and  a presets-name to ID map.

I have no opinion about the de/serialization format. turtle is fine with
me, as would be JSON-LD. Both can be efficiently parsed (low CPU, low
memory, serial I/O) and satisfy requirements (semantic description,
ordered data structure).

> Then we could all simply use our same LV2 discovery codes to examine
>  all plugin types found.

I'm not sure if that's very likely, nor practical. While serd/sord are
generic to deal with turtle/RDF, liblilv is rather specific for LV2. The
mechanism to scan/discover plugins and presets is rather different for
each standard.

Realistically, these days the only interesting plugin formats are LV2,
VST and AudioUnit.

VST does not even specify a system-wide install location for discovery.
The AU format is abstracted by Apple, you can't directly interact with
it but have to use Apple's libs. This leaves LV2.


On a related 

Re: [LAD] New(ish) OSS synth plugin

[Robin Gareus]

On 09/27/2018 02:43 PM, Kjetil Matheussen wrote:
[...]

> For anyone who wants to give it a try,
> it might be that it's enough just using a
> newer version of VSTGUI and gtkmm than I did.
> I used gtkmm 3.16 and gtk-3.3, which probably
> are some years old old. The VSTGUI I used,
> I don't know how hold is, or where it came from.

Indeed, try to update.

VST3's VSTGUI recently removed all gtk from their toolkit.
That greatly helps to produce distributable plugins (since gtk cannot be
statically linked and also has ABI issues when combined other toolkits).

Cheers!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] PipeWire

[Robin Gareus]

On 02/19/2018 09:39 AM, Wim Taymans wrote:
[...]
> I would very much like to hear your ideas, comments, flames, thoughts on this
> idea. I think I'm at a stage where I can present this to a bigger audience and
> have enough experience with the matter to have meaningful discussions.

Hi Wim,

I think the general lack of enthusiasm about pipewire here is because it
does not solve any issues for linux-audio and at best does not
introduces new ones.

In the past years the most prominent question that I have received is

 * How can I use all of my USB Mics with Ardour on Linux?
 * How do I uniquely identify my many MIDI devices?
 * Why does my audio device not have proper port-names?
 * Why can't I re-connect my device and resume work?

These questions are mostly from Mac or Windows users moving to Linux ...
and many of them moving back to MacOS.

While it is not impossible to combine multiple devices, it is not a
straightforward to set this up. Manging devices uniquely and handling
temporarily missing devices is not possible on GNU/Linux AFAIK.

If you try to come up with a new system (think pipewire), please copy as
many concepts as possible from Mac's CoreAudio.

Both pulseaudio and jack had the correct idea to present audio as a
service to applications. The server is concerned with device(s) and
device settings. However, both fail to abstract multiple devices, map
their port uniquely and provide multiple apps to concurrently use those
devices for different purposes.

The main issue with pulse is that it is a poll API. Also pulseaudio's
per device, per port-latency is incorrect (if set at all). JACK on the
other hand is too limited: single device, fixed buffersize. jackd also
periodically wakes ups the CPU and uses power (even if no client is
connected).

Browsing around in the pipewire source I see several potential design
issues.

In particular data format conversions: The nice part about JACK is that
uses float as only native format. Also port-memory is shared between
application with zero-copy.

In pipewire a port can be any data-type including vorbis and worse MIDI
is a bolted-on sub-type on an audio port.

JACK-MIDI has in the past been criticized most because MIDI was a
dedicated type instead of JACK providing generic event-ports.

Another conceptual issue that I see with pipewire is that it pushes sync
downstream (like gstreamer does), instead of sources being pulled
upstream. This in particular will make it hard to compensate for
latencies and align outputs.

Implementation wise there are plenty of other issues remaining to be
discussed, e.g. context-switches, resampling, process-graph,.. but those
are not important at this point in time.

Cheers!
robin



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#897889: x42-plugins: ftbfs with GCC-8

[Robin Gareus]

This was fixed upstream early 2018.

check uscan, debian/watch: The latest release is
https://gareus.org/misc/x42-plugins/x42-plugins-20180320.tar.xz
and includes the fix.

Bug#897889: x42-plugins: ftbfs with GCC-8

[Robin Gareus]

This was fixed upstream early 2018.

check uscan, debian/watch: The latest release is
https://gareus.org/misc/x42-plugins/x42-plugins-20180320.tar.xz
and includes the fix.

Bug#897889: x42-plugins: ftbfs with GCC-8

[Robin Gareus]

This was fixed upstream early 2018.

check uscan, debian/watch: The latest release is
https://gareus.org/misc/x42-plugins/x42-plugins-20180320.tar.xz
and includes the fix.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [LAD] Github DCMA takedown notice - VeSTige header

[Robin Gareus]

On 06/05/2018 09:45 AM, Filipe Coelho wrote:
> On 05.06.2018 01:18, Robin Gareus wrote:
>> Hi LADs,
>>
>> I was contacted earlier today by GitHub with a DCMA request from
>> Steinberg.net to remove the aeffectx.h from VeSTige. [1]
> 
> Oh wow, incredible timing with Microsoft buy out.

Honi soit qui mal y pense.

> Do you think renaming aeffectx.h will be enough?

The filename does match a filename of the official Steinberg VST SDK.
I've added a disclaimer and clarified that is vestige.

It may well be that this is part of a larger outreach. grep all of
github for plugins that ship aeffectx.h.

If you the DCMA notice carefully, you'll fine that they did not even
follow github's guide to do so. It may well be some semi-automated process.

I guess we'll find out, the 24h will expire 21:55 CEST today.

> It is their API, which they might feel entitled to sue over.

Only in the US of A. APIs are not (C) in the EU.
The vestige header is a pure API without any implementation.

>> I have no idea why Steinberg would target this rather low profile
>> project, but there you go.
> 
> Likely because of the name. lv2vst sounds "dangerous" :P
> 
> Sadly, if they insist on this, it will only be trouble for opensource
> applications.
> Ardour, Qtractor, Carla, MusE, LMMS and others all use this vestige
> header... making it "illegal" would mean our beloved tools will simply
> drop VST support.

Those are hosts though. Except for Carla which can be both.

> This is now how they convince developers to change to VST3 at all...

If this is indeed only about plugin (not hosts), then this would explain
it. I am curious if other plugin authors also received a notice.

For hosts, I would be able to ignore the fact the VST3 SDK is a
kitchen-sink and with a bad conscience also tolerate UTF-16, but VSTGUI4
depending on GTK on Linux is a no-go.

> rather, just makes me want to remove all VST related things from my
> system, damn bastards.

LV2 FTW!
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Github DCMA takedown notice - VeSTige header

[Robin Gareus]

Hi LADs,

I was contacted earlier today by GitHub with a DCMA request from
Steinberg.net to remove the aeffectx.h from VeSTige. [1]

I am planning to contest the DCMA request. This will ideally happen with
some legal counsel and support from Javier Serrano Polo who is the
original (C) holder of the VeSTige header and reverse engineered the API.

Since Github requires action within 24 hours, I have meanwhile complied
and force-pushed
https://github.com/x42/lv2vst/blob/master/include/aeffectx.h out of
existence.

I have no idea why Steinberg would target this rather low profile
project, but there you go.

Cheers!
robin


[1] Search the web for
"aeffectx.h - simple header to allow VeSTige compilation and eventually
work"
and you will find the exact file in various places.


In case you're wondering how a github DCMA notice looks like:

- - -

**Are you the copyright owner or authorized to act on the copyright
owner’s behalf?**
Yes

**Please provide a detailed description of the original copyrighted work
that has allegedly been infringed. If possible, include a URL to where
it is posted online.**
https://www.steinberg.net/en/company/developers.html

**What files should be taken down? Please provide URLs for each file, or
if the entire repository, the repository’s URL:**
https://github.com/x42/lv2vst/blob/master/include/aeffectx.h

**Have you searched for any forks of the allegedly infringing files or
repositories? Each fork is a distinct repository and must be identified
separately if you believe it is infringing and wish to have it taken
down.**
no

**Is the work licensed under an open source license? If so, which open
source license? Are the allegedly infringing files being used under the
open source license, or are they in violation of the license?**
no

**What would be the best solution for the alleged infringement? Are
there specific changes the other person can make other than removal?**
no

**Do you have the alleged infringer’s contact information? If so, please
provide it:**


**Type (or copy and paste) the following statement: "I have a good faith
belief that use of the copyrighted materials described above on   the
infringing web pages is not authorized by the copyright owner, or its
agent, or the law. I have taken fair use into consideration."**
"I have a good faith belief that use of the copyrighted materials
described above on the infringing web pages is not authorized by the
copyright owner, or its agent, or the law. I have taken fair use into
consideration."

**Type (or copy and paste) the following statement: "I swear, under
penalty of perjury, that the information in this notification is
accurate and that I am the copyright owner, or am authorized to act on
behalf of the owner, of an exclusive right that is allegedly infringed."**
"I swear, under penalty of perjury, that the information in this
notification is accurate and that I am the copyright owner, or am
authorized to act on behalf of the owner, of an exclusive right that is
allegedly infringed."

**Please confirm that you have you have read our Guide to Submitting a
DMCA Takedown Notice:
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/**

yes i confirm

**So that we can get back to you, please provide either your telephone
number or physical address:**
[private]
[private] Phone: [private]
Steinberg Media Technologies GmbH Fax : [private]
[private]
http://www.steinberg.net

**Please type your full legal name below to sign this request:**
[private]
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: Bug#900705: x42-plugins FTCBFS: many reasons

[Robin Gareus]

Hi Helmut,

Thanks for looking into this! The PKG_CONFIG patch is potentially
useful, although I don't see why this is required. The plugins cross
compile just fine here.

Your patch does however include debian/* files and also seems to include
some changes other than s/pkg-config/$(PKG_CONFIG)/.

Do you maintain your work in a git repo? If so it would be handy to
export each of the patches separately, since upstream maintains the
projects as separate repos: https://github.com/x42/x42-plugins


To be honest I'd rather see these plugins be removed from debian until
they're statically linked and self-contained. As I've explained
countless times in the past, dynamically linking audio-plugins is
problematic and incorrect.

Cheers!
robin

On 06/03/2018 08:00 PM, Helmut Grohne wrote:
> Source: x42-plugins
> Version: 20170428-1.1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> x42-plugins fails to cross build from source for a pile of reasons.
> First and foremost, the Makefiles hard code the build architecture
> pkg-config. Allowing substitution produces quite a big cross.patch, but
> that part should be upstreamable. Then the packaging needs to pass cross
> compilers and a cross pkg-config to make. Furthermore, stripping (with
> the build architecture strip) fails. Stripping not just breaks cross
> compilation, but also generation  -ofdbgsym packages, so disable it
> entirely. The attached patch makes x32-plugins cross buildable. Please
> consider applying it.
> 
> Helmut
> 
> 
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
> 


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#890672: fixed in x42-plugins 20170428-1.1

[Robin Gareus]

Hi,

Why don't you update to x42-plugins-20180320 which was released about
two weeks ago and also fixes this issue?

see https://tracker.debian.org/pkg/x42-plugins it has an "action
needed", high-prio item for it.

Cheers!
robin

PS. As opposed to what tracker.debian.org says, the package does not
depend on libpugl-dev, feel free to remove the build-dep while you're at it.



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#890672: fixed in x42-plugins 20170428-1.1

[Robin Gareus]

Hi,

Why don't you update to x42-plugins-20180320 which was released about
two weeks ago and also fixes this issue?

see https://tracker.debian.org/pkg/x42-plugins it has an "action
needed", high-prio item for it.

Cheers!
robin

PS. As opposed to what tracker.debian.org says, the package does not
depend on libpugl-dev, feel free to remove the build-dep while you're at it.



signature.asc
Description: OpenPGP digital signature

Bug#890672: fixed in x42-plugins 20170428-1.1

[Robin Gareus]

Hi,

Why don't you update to x42-plugins-20180320 which was released about
two weeks ago and also fixes this issue?

see https://tracker.debian.org/pkg/x42-plugins it has an "action
needed", high-prio item for it.

Cheers!
robin

PS. As opposed to what tracker.debian.org says, the package does not
depend on libpugl-dev, feel free to remove the build-dep while you're at it.



signature.asc
Description: OpenPGP digital signature

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[Robin Gareus]

The recent backport kernel does *not* have this issue. All is fine with

 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14)

This is on a Thinkpad X250 with 00:02.0 VGA compatible controller: Intel
Corporation HD Graphics 5500 (rev 09)

4.9.0-4-amd64 and 4.9.0-5-amd64 on the same box do cause screen flickering.



Chances are that the issue was introduced by the update to upstream
4.9.46. There are a handful of "drm/i915" changes:

https://anonscm.debian.org/git/kernel/linux.git/commit/?h=debian/4.9.65-3%2bdeb9u2&id=17811b5a4b11b32307baca3b88067398a1168cfb

"Workaround VLV/CHV DSI scanline counter hardware fail" sounds
suspicious, but that's just a guess.

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly with Radeon R9 270X since upgrade from 4.9.0-3 to 4.9.0-4

[Robin Gareus]

The recent backport kernel does *not* have this issue. All is fine with

 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14)

This is on a Thinkpad X250 with 00:02.0 VGA compatible controller: Intel
Corporation HD Graphics 5500 (rev 09)

4.9.0-4-amd64 and 4.9.0-5-amd64 on the same box do cause screen flickering.



Chances are that the issue was introduced by the update to upstream
4.9.46. There are a handful of "drm/i915" changes:

https://anonscm.debian.org/git/kernel/linux.git/commit/?h=debian/4.9.65-3%2bdeb9u2&id=17811b5a4b11b32307baca3b88067398a1168cfb

"Workaround VLV/CHV DSI scanline counter hardware fail" sounds
suspicious, but that's just a guess.

[Sursound] LAC 2018 : Call for Papers / Posters / Workshops/ Music Performances / Multimedia Installations

[Robin Gareus]

[Apologies for cross-postings] [Please distribute]

Conference date: 7th - 10th June 2018

The Linux Audio Conference 2018 will be hosted at c-base, Berlin -
in partnership with the Electronic Music Studio (TU Berlin) and Spektrum.

https://lac.linuxaudio.org/2018

Deadline for all submissions: Friday, February 28th, 2018 (23:59 UTC)

- - -

1: Call for Papers / Posters / Workshops

LAC 2018 invites submissions of papers, posters and workshops addressing
all areas of audio processing based on Linux and open source software.
All submissions and presentations are in English. All submissions are
peer reviewed by a committee of experts from different disciplines.
Submissions can focus on technical, artistic or scientific issues and
can target developers or users.

For more details see the website:

   https://lac.linuxaudio.org/2018/pages/cfp/

*Papers*
Papers must be written and presented in English.
The length of papers is 4 to 8 pages, with up to 5 keywords, and an
abstract of up to 200 words.


The poster presentations are based on paper submissions of  2-4 pages,
with up to 5 keywords and an abstract of up to 150 words.

*Workshops*
The workshop presentation (max duration of 2h) should be 1-4 pages, with
up to 5 keywords,  and an abstract of up to 150 words to be published on
the conference website. Submit a brief description of the workshop
including URL (if available).

How to submit?
* Use the OpenConf online submission tool at
https://lac.linuxaudio.org/2018/openconf
* Select the relevant submission type ('_ PAPER  _' / '_ POSTER  _' / '_
WORKSHOP  _')
* The required file format is PDF, formatted for A4 paper. Authors are
required to use the templates for paper formatting available as download
on the conference website.
* Please notify us if you need a special technical setup for your
presentation.

- - -

2: Call for Music Performances / Multimedia Installations

LAC 2018 also invites submissions of Electroacoustic Works and
Multimedia Installations. A jury will select the compositions and
installations to be included in the conference program according to
artistic merit and technical feasibility.

Please be prepared to perform your work yourself and make sure that you
have all resources needed to perform your piece at your disposal (e.g.
instruments, other performers, etc.).

Unfortunately, LAC 2018 cannot pay a fee neither for you nor for any
additional performers, and LAC 2018 cannot organize or pay for travel or
accommodation neither for you nor for any additional performers.
All submissions are peer reviewed by a committee of experts in music and
arts.

Electroacoustic Works and Multimedia Installation can address all areas
of digital audio and audiovisual art.

Available Technical Setups
For concerts, the LAC will provide the following equipment:
* 8-channel - speaker setup
* Stereo setup + video projection
* Digital mixing desk
Additional requests can not be guaranteed.

How to submit?
* Use the OpenConf online submission tool at
https://lac.linuxaudio.org/2018/openconf
* Select the submission type '_ PERFORMANCE _'
* The required file format is PDF, formatted for A4 paper. It includes:
  * Description of the project program notes
  * Link to video or audio demonstration of the project
  * Technical rider of the work

Important Dates
* Deadline for all submissions: Friday, February 28th, 2018 (23:59 UTC)
* Acceptance notification: March 31st, 2018
* Final deadline for 'camera ready' paper: April 15th, 2018
* Author registration deadline: April 15th, 2018
* Final program: May 1st, 2018


Up-to-date information regarding the conference can be found on its website:

https://lac.linuxaudio.org/2018


Looking forward to seeing you in Berlin!

The Linux Audio Conference 2018 team
___
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound - unsubscribe here, edit 
account or options, view archives and so on.

Re: First deprecate APIs and then remove them in the next major version

[Robin Gareus]

On 12/24/2017 04:01 PM, Christian Schoenebeck wrote:
> On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote:
>> ​actually, my impression from interactions with the author is that GTK
>> didn't make their life miserable at all.

It was main gdk in that context. A basic window and event system
abstraction.

>> however, the issues that have been mentioned before regarding host/plugin
>> toolkit interactions did make their (and users') lives miserable, hence the
>> switch.​
> 
> The trend among DAW apps is going towards process separation for plugins (one 
> process for all instances of a plugin). No plans for that in Ardour yet?
> 

Process-separation requires a context-switch which is very expensive and
does not scale [1]. There are no plans to add this to Ardour.

ciao,
robin

[1]
http://lists.ardour.org/pipermail/ardour-users-ardour.org/2015-August/027373.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly since upgrade from 4.9.0-3 to 4.9.0-4

[Robin Gareus]

Same issue with 4.9.0-4-amd64, same workaround (use 4.9.0-3-amd64)

Thinkpad X250
VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

What information would be relevant or useful to provide?

Bug#878221: linux-image-4.9.0-4-amd64: Screen flickers randomly since upgrade from 4.9.0-3 to 4.9.0-4

[Robin Gareus]

Same issue with 4.9.0-4-amd64, same workaround (use 4.9.0-3-amd64)

Thinkpad X250
VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

What information would be relevant or useful to provide?

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/12/2017 04:02 PM, Gordonjcp wrote:

> That doesn't answer the question, really.  For one thing, statically
> linking *anything* is utterly ridiculous and anyone doing that now or
> indeed at any point in the past 30 years of Unix development should have
> their hands cut off.

Keep in mind that audio plugins are not unix.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/04/2017 06:52 PM, Jörn Nettingsmeier wrote:
> On 12/04/2017 01:30 PM, Robin Gareus wrote:
> 
>> Seeing as this was in a train, and last I looked the DB-network was wide
>> open, I'm curious if this was actually a hack by guy in another
>> train-compartment or perhaps a subverted access-point exploiting some OS
>> X vulnerability.
> 
> I was connected to my own phone hotspot. So unless it's a very low-level
> WLAN interface vulnerability, a local wireless exploit seems unlikely.
> 
> I'm pretty sure the kill message did come from the iCloud (a service
> which I'm not using and which I don't indent to ever use) using the
> Find-my-Mac feature. I was _never_ given an option to opt out of this
> feature, and it was never made clear to me that I was carrying a
> time-bomb (with remote wipe option) that would enable unknown third
> parties to potentially cause five-digit damages on a whim.

It's probably all in some EULA smallprint, and your visit to the
Apple-store will be rather unspectacular.

You said earlier "[the macbook] had been factory-reset and completely
installed from scratch." According to the doc, clearing the NVRAM or
PRAM should disable "Find-My-Mac". Then again, since any Apple-store can
un-brick it if you show them a proof-of-purchase, there's yet another
backdoor...

Anyway, I'm glad you were able to get all the data from it.
May I ask how? http://www.system-rescue-cd.org/ ?

Cheers!
robin

PS. As atonement for your sin, I suggest hosting the next Linux Audio
Conference ;-))
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Robin Gareus]

On 12/04/2017 11:52 AM, Louigi Verona wrote:
> You should also understand that millions of people are
> using Macs everyday and their data doesn't get lost, right?

I actually don't know a Mac user who hasn't been burnt and they all use
TimeCapsules or iCloud or dropbox or a similar backup solution.

I've seen a many master-students who are writing their thesis on OS X to
send it to themselves or friends by email every other hour as backup.
Only few of them embraced git, because sending an email is just too trivial.


Anyway Joern's story is not about loosing files, but being locked out of
the machine (!).

Seeing as this was in a train, and last I looked the DB-network was wide
open, I'm curious if this was actually a hack by guy in another
train-compartment or perhaps a subverted access-point exploiting some OS
X vulnerability.


> Because, if not, I can supply many-many stories where I would loose data
> because of stupid Linux machines, lose gigs because suddenly the music
> software wouldn't start, although it did just yesterday. There are enough
> problems that stem from software not having an owner that from it "being
> controlled" by someone else. And then after bashing Linux, I can finish my
> email with a dramatic "don't".
> 
> Any system can fail, and it is never at the right time. And in my
> experience, proprietary systems are generally much more stable than floss,
> and are less likely to fail suddenly and without warning.
> 
> For instance, when preparing for the Sonoj convention, I had Carla start
> crashing on me and I could not complete music examples. I eventually had to
> revert to FLStudio to make them.
> 
> At the Sonoj Convention, 10 minutes before my dj set, Mixxx has deleted all
> of my tracks library and I had to frantically search for a fix. I found a
> workaround, but could not include a couple of new tunes into the set.
> 
> Did I write a post blaming floss for that? No.

I very much hope you did file bug reports for all those issues.


While the end-result may be the same: "fail to deliver result". Joern's
experience is quite different from what you describe.

Also note that all the software that you have mentioned comes with a
disclaimer (GPL):

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

..writing a blaming blog post is a non-starter if you accept the license.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Robin Gareus]

Note that the LV2 event extension was deprecated years ago
and the last plugins which were using it were /killed/ in 2014.

http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-January/000642.html


As for the bug report itself, changing plugin API specifications
post-factum is never a good idea. So uint8_t it is, besides the
documentation in event.h makes it clear:

/**
The contents of the event buffer. This may or may not reside in the
same block of memory as this header, plugins must not assume either.
The host guarantees this points to at least capacity bytes of allocated
memory (though only size bytes of that are valid events).
*/
uint8_t* data;


not a bug.

On 08/11/2017 08:20 PM, Joël Krähemann wrote:
> Hi
> 
> For sure you can cast any pointer. But feels somehow wrong. The
> opinion was the specs
> are always correct.
> 
> Bests,
> Joël
> 

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#871649: lv2-dev: abuse of non portable pointer of uint8_t type

[Robin Gareus]

Note that the LV2 event extension was deprecated years ago
and the last plugins which were using it were /killed/ in 2014.

http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-January/000642.html


As for the bug report itself, changing plugin API specifications
post-factum is never a good idea. So uint8_t it is, besides the
documentation in event.h makes it clear:

/**
The contents of the event buffer. This may or may not reside in the
same block of memory as this header, plugins must not assume either.
The host guarantees this points to at least capacity bytes of allocated
memory (though only size bytes of that are valid events).
*/
uint8_t* data;


not a bug.

On 08/11/2017 08:20 PM, Joël Krähemann wrote:
> Hi
> 
> For sure you can cast any pointer. But feels somehow wrong. The
> opinion was the specs
> are always correct.
> 
> Bests,
> Joël
> 

Re: [LAD] OSC-generating plugin?

[Robin Gareus]

On 06/19/2017 11:57 PM, Jörn Nettingsmeier wrote:
> the customer is always right

Doesn't sound like the right customer though :-)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] OSC-generating plugin?

[Robin Gareus]

On 06/19/2017 08:07 PM, Jörn Nettingsmeier wrote:
> Hi *!
> 
> Does anybody know of a decent free plugin that generates arbitrary OSC
> command streams from plugin automation data in the DAW? Preferrably
> (gasp!) VST? Idea is to use SomeEvilDAW to send and control smart things
> on a box running a friendly OS and a FriendlyDAW.

Sending OSC is not rt-safe and VST parameters are rather limited.
"arbitrary messages" are no fun and need all kinds of hacks (eg sending
them from the UI thread). There are a couple of single-parameter VSTs
though.

Along those lines there's an ancient LADSPA plugin, too:
https://code.google.com/archive/p/noisesmith-linux-audio/downloads
needs some CFLAGS=-fPIC but otherwise still compiles, but it probably
won't run in SomeEvilDAW.

A more generic solution: https://github.com/x42/jackmidi2osc
Receive MIDI from someplace, generate fancy OSC based on rules.

Spencer wrote a similar tool https://github.com/ssj71/OSC2MIDI/ which
despite its name can also turn MIDI into OSC.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] LAC 2017 Program - Linux Audio Conference in Saint-Etienne

[Robin Gareus]

On 05/02/2017 08:58 PM, Albert Graef wrote:
> On Tue, May 2, 2017 at 8:53 PM, Fons Adriaensen  wrote:
> 
>> Doesn't need to be pizza, but please no *foie gras* for me :-)
>> Looking at the list of restaurants I noticed this:
>>
>>   
>>
> 
> Looks good to me, and not far from the university.
> 

Lebanese is great. Count me in. ~19h?!

looking forward,
robin




signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Bug#649824: recordmydesktop: Specifying --use-jack makes recordmydesktop exit with a bad screen geometry

[Robin Gareus]

Package: recordmydesktop
Version: 0.3.8.1+svn602-1+b1
Followup-For: Bug #649824

Dear Maintainer,

The issue is still present and caused by an upstream bug/typo.
--use-jack sets the parameter also used by the --x option.
 (src/rmd_parseargs.c:194)

A workaround is to order the options: --use-jack .. -x 0


Related issue with --use-jack is that poptGetOptArg() does not iterate
correctly over space separate arguments. So at most a single
jack port can be used, and jack-ports with spaces are not possible.
A

Attached patch resolves both issues, by allowing incremental
--use-jack options.

e.g. to record a stereo file:

  recordmydesktop --width=1920 --height=1072 --fps=25 -o /tmp/test.ogv \
-x 0 -y 0 --use-jack system:capture_1 --use-jack "jackapp:Right Channel"


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages recordmydesktop depends on:
ii  libasound21.1.2-1
ii  libc6 2.23-5
ii  libice6   2:1.0.9-1+b1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-2
ii  libogg0   1.3.2-1
ii  libpopt0  1.16-10
ii  libsm62:1.2.2-1+b1
ii  libtheora01.1.1+dfsg.1-14
ii  libvorbis0a   1.3.5-3
ii  libvorbisenc2 1.3.5-3
ii  libvorbisfile31.3.5-3
ii  libx11-6  2:1.6.3-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  zlib1g1:1.2.8.dfsg-2+b1

recordmydesktop recommends no packages.

recordmydesktop suggests no packages.

-- no debconf information
Index: recordmydesktop-0.3.8.1+svn602/src/rmd_parseargs.c
===
--- recordmydesktop-0.3.8.1+svn602.orig/src/rmd_parseargs.c
+++ recordmydesktop-0.3.8.1+svn602/src/rmd_parseargs.c
@@ -191,7 +191,7 @@ boolean rmdParseArgs(int argc, char **ar
   "SOUND_DEVICE" },
 
 { "use-jack", '\0',
-  POPT_ARG_STRING | RMD_USE_JACK_EXTRA_FLAG, &arg_return->x, RMD_ARG_USE_JACK,
+  POPT_ARG_STRING | RMD_USE_JACK_EXTRA_FLAG, NULL, RMD_ARG_USE_JACK,
   "Record audio from the specified list of space-separated jack ports.",
   "port1 port2... portn" },
 
@@ -350,9 +350,7 @@ boolean rmdParseArgs(int argc, char **ar
 
 case RMD_ARG_USE_JACK:
 {
-arg_return->jack_nports = 0;
-
-while (arg) {
+while (arg && arg_return->jack_nports < RMD_MAX_JACK_PORTS) {
 
 arg_return->jack_nports++;
 

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/22/2016 07:30 PM, Tito Latini wrote:
> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
> [...]
>> > Ableton have now done that, albeit by circumventing the hardest parts of
>> > the problem (a tempo map with varying meter and tempo).
> What?
> 
> I repeat: that's not an innovation.

Did anyone say it was? Why does it matter if it's innovation?

Compared to all the prior-art, I suppose the interesting part of Link is
momentum behind it, along with the apple-style dictated protocol: take
it as-is or leave it. Not the usual years of consortium design
discussions which may or may not eventually result in consensus and more
like a floss-like benevolent dictator style (think jack, or LV2).

The closest thing to innovation is "Pro Audio company that usually does
closed-source proprietary software publishes an API and reference
implementation under GPLv2" and it work on GNU/Linux, too.

That's pretty cool IMHO and I wish more companies would do that!

Also coming up with a protocol is the easier part. Documenting it,
pushing it out to users, gaining traction in the industry etc is the
hard part.

2c,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/21/2016 12:24 PM, Perry Nguyen wrote:
> I am still vaguely under the impression that if a Timebase master client is
> Link-capable then any transport-aware client (e.g. most LAU apps today)
> would be able to follow any tempo changes described by the master and
> therefore automatically have "Link support"

Theoretically, yes. A jack timebase master is supposed to translate
current absolute position to musical time. It's mainly useful for
tempo-maps.

Ableton Link does not provide an absolute reference, so the client would
have to maintain an internal count depending on transport state, infer
that information and keep track.

Still jack-position is versatile enough to represent information
provided by Link:

http://jackaudio.org/files/docs/html/structjack__position__t.html

The real question is if it's useful and how many jack-apps
can cope with potentially non-linearity WRT to absolute jack transport
sample time.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/20/2016 01:40 PM, Patrick Shirkey wrote:
> 
>> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>>
>>> Because netjack isn't good enough
>>
>> correct.
>>
>> jack can have a single timebase master and likewise netjack has a single
>> net-master.
>>
>> Ableton-Link is decentralized: Multiple performers can interact with
>> each other on an equal level (no master/slave semantics).
>>
>> It's not groundbreaking tech. Laptop orchestras and the likes have used
>> similar techniques since a while, but all prior-art that I know is ad-hoc.
>>
>> As far as I know this is the only protocol concerning *musical-time*
>> that's spec'ed out, has a cross-platform reference implementation and
>> potential to find its way into hardware.
>>
>> Feel free to criticize the protocol on a technical level or hunt for
>> bugs in the implementation ... or simply ignore it silently.
>>
> 
> So then the next question would be is there any reason NOT to integrate it
> directly into JACK?
> 

There's an existing feature request already: [1]


JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.

Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack
transport.

So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.

Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).

There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.


Cheers!
robin


[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
> 
> Because netjack isn't good enough 

correct.

jack can have a single timebase master and likewise netjack has a single
net-master.

Ableton-Link is decentralized: Multiple performers can interact with
each other on an equal level (no master/slave semantics).

It's not groundbreaking tech. Laptop orchestras and the likes have used
similar techniques since a while, but all prior-art that I know is ad-hoc.

As far as I know this is the only protocol concerning *musical-time*
that's spec'ed out, has a cross-platform reference implementation and
potential to find its way into hardware.

Feel free to criticize the protocol on a technical level or hunt for
bugs in the implementation ... or simply ignore it silently.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
> 
>> why?
>>
>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini 
>> wrote:
>>
>>> What is the content of the network packets ?
>>>
>>> Regardless, I'll ignore software with that technologogy.
>>
> 
> The OP seems to be suggesting that whoever has access to the data captured
> by Ableton Link or the potential backdoor that link *might* enable would
> use it for nefarious purposes.

Ableton link is used to synchronize software and devices on a *LAN*.
It basically broadcasts BPM and song-position to the *local* network.

Link does not allow to synchronize devices on a WAN.

The complete source code is free (GPLv2) you can read it, no strings
attached.

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: Ardour 5.0

[Robin Gareus]

On 08/29/2016 08:56 PM, Jaromír Mikeš wrote:

>> the suggestion about the custom CGI script sounds great.
> 
> Hi Robin,
> 
> do you read the our list regularly or we should keep you in copy?

yes, I did see IOhannes' reply.

> I second IOhannes about CGI script ... it would be really helpful.

I spoke with Paul and he's also OK to also provide a versioned link.

Proposed (not yet working)

  https://community.ardour.org/src/

returns

-8<---
Ardour Source

ardour-5.3.0.tar.bz2

-8<---

That should be trivial for uscan.

Alas, I'm traveling this week and will probably not get this in place
before early Sept, but certainly will before 5.4.

> BTW IOhannes ardour 5.3 is out ;)

Get it while it's hot: https://community.ardour.org/srctar :)

Cheers!
robin


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Ardour 5.0

[Robin Gareus]

tl;dr: We can't offer a better solution for the time being

On 08/28/2016 02:19 PM, Jaromír Mikeš wrote:
>>>
>>> ardour 5.1 is out ... I still don't have a idea how get a tarball :(

And 5.3 will be out later today :)

https://community.ardour.org/srctar is a direct link to the latest
upstream source of released version (currently still 5.1.0).

>> indeed the github download seems to be very broken.
>> it seems that this is intentional (at least that is how i interpret the
>> line `/* export-ignore` in .gitattributes¹).
>> i guess this is to force people to download via the ardour website².
>> ...

The motivation is different. As IOhannes already mentioned, Ardour
relies on `git describe` to work in order to extract the version.
Shallow git clones fail for the same reason.

One needs to run `./waf dist` on a full git clone in order to generate
libs/ardour/revision.cc prior to export. Github does not allow that.
GH does also not allow one to disable snapshots.

It was a very practical thing. After blacklisting the files, the
support-rate on #ardour IRC dropped significantly. I suppose most users
don't read the README, nor 'configure' output,  but they do understand
"empty zip". :)

If there's anything we can do to make debian packaging easier without
adding more 'newbie' support load on our end, I'll gladly do the
required changes.


The actual problem: We do not want to maintain version information in
multiple places. git tags are awesome.

Sadly gitattributes export-subst can only use information that is
available to git-log. One cannot currently walk the tree as git-describe
does.

Closest thing we've found is
http://stackoverflow.com/questions/19659976/add-tag-in-export-subst-file
but GH does not allow one to run arbitrary smudge filter commands either.

If you have a better solution, please don't hesitate to tell.

We're currently looking into getting `git describe` as supported feature
for export-subst upstream at git. But that's rather long term.

>> anyhow, i just fetched the upstream tarball and ran gbp-import-orig on it.
>> it should be possible (and possibly simple) to hack the d/watch to run
>> the actual download from the official download site, and use github only
>> as an announcement channel to check for new releases.

That sounds sensible to me, at least short/mid term. I suggest to add a
24h delay, though:

The git tag is the very first step in a release-cycle and as it happened
in the past (4.3, 4.5) and just now again with 5.2, the ensuing testing
after the tag may result in another version bump.

The "proper" way would be to parse the first  from
https://ardour.org/whatsnew.html That page is updated as last step every
release cycle.

If it helps I could set up a CGI script on ardour.org that is uscan
compatible. but I'll need some help to work around the missing
version-number in the upstream URL. Does uscan support Content-Disposition ?

ciao,
robin

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [Linuxsampler-devel] LS licensing -- was Linuxsampler and Zynthian Project

[Robin Gareus]

On 07/07/2016 07:56 PM, RDP wrote:
> On 6 July 2016 at 17:28, Christian Schoenebeck
>  wrote:
[..]
>> Anyway, I approved your forum user, so you should be able to post now on all
>> forums without moderation. And I also changed the board's settings so that
>> newly registered users can at least immediately post on the "Newbies &
>> Support" section without having to wait for a moderator passing by after
>> weeks. ;-)
> 
> Thank you.  After recent list exchanges I decided to start the ball
> rolling.. however, I rather suspect now, that apathy will reign and
> silence on the matter will be truly deafening!
> 
> You mentioned previously, bumping licensing to a separate forum
> section, and making it 'sticky'.  Possily still worth doing, so as the
> matter doesn't get lost in the myriad of postings! ;o)

Cool, thanks a lot.

I do have a drafted reply to an earlier message on the ML here. I'll
copy that over there.

Cheers!
robin

--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel