Hi all,
New images are ready for testing (amd64, i386) ;)
io GNU/Linux is a Live DVD/USB based on Debian Sid and focused on multimedia.
-> Kernel 4.14 and 4.14-rt1, Jack2+PulseAudio as default sound server (can
be easily changed to Jack2+AlsaLoop, Jack2+ZitaBridge, PulseAudio or Alsa)
-> Enlig
I think it's also worth mentioning that although MacOS and Windows
generally have an easier time with this stuff, they too sometimes can
suffer from plugin/host toolkit/runtime wierdness.
There's a case under discussion right now on the coreaudio mailing list
involving a very smart, very long-time
On 10.12.2017 22:19, Filipe Coelho wrote:
> On 10.12.2017 22:14, Markus Seeber wrote:
>> Hm, I did not think about that hard enough, honestly. Then again this makes
>> me want to explore the idea of a plugin GUIs separately from the DAW process.
>> This is not a new idea, but has it already been im
On 10.12.2017 22:14, Markus Seeber wrote:
Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in
detail,
apart from the o
On 12/10/2017 09:37 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>> You can still statically link for example with FLTK
>>
> You still need to ensure that the host can integrate with FLTK (or any
> other toolkit's) event loop.
On Sun, Dec 10, 2017 at 7:43 PM, Gordonjcp wrote:
Previous discussion about plugins using GUI library frameworks like
Gtk/QT, which are not designed for plugin usage. As a result, they export
symbols that may collide when loaded in a DAW and plugin, when DAW and
plugin are compiled against diffe
On 2017-12-10 21:57:06 (+0100), Ralf Mardorf wrote:
> But please, developers consider to sign your tarballs.
+1
--
https://sleepmap.de
signature.asc
Description: PGP signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https
On Sun, 10 Dec 2017 21:52:30 +0100, David Runge wrote:
>You rule!
>Thanks
+1
But please, developers consider to sign your tarballs.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-d
You rule!
Thanks
--
https://sleepmap.de
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
On 11/26/2017 04:10 PM, David Runge wrote:
> That is good news and I'm looking forward to it!
>
> Note, that letsencrypt certificates can easily be setup using SAN
> (Subject Alternative Name), which gets around the need for a wildcard
> certificate (unless you literally have hundreds of subdomain
On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
markus.see...@spectralbird.de> wrote:
> You can still statically link for example with FLTK
>
You still need to ensure that the host can integrate with FLTK (or any
other toolkit's) event loop. Without some explicit awareness, events etc.
will ne
On 12/10/2017 08:43 PM, Gordonjcp wrote:
> On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote:
>> On 12/10/2017 03:31 PM, Paul Davis wrote:
>>> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
>>> markus.see...@spectralbird.de> wrote:
>>>
Just employ static linking when sensi
On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote:
> On 12/10/2017 03:31 PM, Paul Davis wrote:
> > On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> > markus.see...@spectralbird.de> wrote:
> >
> >>
> >> Just employ static linking when sensible.
> >
> > unortunately, several large to
On 12/10/2017 03:31 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>>
>> Just employ static linking when sensible.
>
> unortunately, several large toolkits of various types make this impossible
> because they themselves use dyna
On Sun, 10 Dec 2017, Markus Seeber wrote:
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.
Just employ static linking when sensible. There are less ways a linker can
screw that up
Often policy gets in the way of
On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
markus.see...@spectralbird.de> wrote:
>
> Just employ static linking when sensible.
unortunately, several large toolkits of various types make this impossible
because they themselves use dynamic (runtime-driven) loading of shared
objects. GTK (
On 12/10/2017 12:14 PM, Filipe Coelho wrote:
> On 10.12.2017 11:51, Markus Seeber wrote:
>> On 12/09/2017 02:32 PM, nils wrote:
>>> Bottom line: It turned out the Windows way of shipping all or most
>>> libs with the program is a really good way to compatibility.
>> Just employ static linking when
On 10.12.2017 11:51, Markus Seeber wrote:
On 12/09/2017 02:32 PM, nils wrote:
Bottom line: It turned out the Windows way of shipping all or most
libs with the program is a really good way to compatibility.
Just employ static linking when sensible.
...
The current way of bundling shared librar
>
> From: nils
>
> Yes, that is possible and I wholeheartly lobby for that because library
> bugs and mismatches are common and could be avoided.
>
> Ardour does it and I do it in my own programs as well, or at least will
> if properly released. If you can copy a library into your source tree
> (P
On 10.12.2017 11:47, Fons Adriaensen wrote:
On Sun, Dec 10, 2017 at 09:33:25AM +0100, Filipe Coelho wrote:
You're missing the fact that all of these are optional dependencies.
Nothing in carla is a real build-time dependency.
So that means that the following (from The AUR PKGBUILD file) is
mos
On 12/09/2017 02:32 PM, nils wrote:
> Yes, that is possible and I wholeheartly lobby for that because library
> bugs and mismatches are common and could be avoided.
>
> Ardour does it and I do it in my own programs as well, or at least will
> if properly released. If you can copy a library into you
On 10.12.2017 11:41, Ralf Mardorf wrote:
On Sun, 10 Dec 2017 11:25:26 +0100, Ralf Mardorf wrote:
Off-topic:
On Sun, 10 Dec 2017 10:51:43 +0100, Filipe Coelho wrote:
In case you did not notice from me and Rui, we Portuguese people like
to support as much stuff as possible :)
Not really. For ex
On Sun, Dec 10, 2017 at 09:33:25AM +0100, Filipe Coelho wrote:
> You're missing the fact that all of these are optional dependencies.
> Nothing in carla is a real build-time dependency.
So that means that the following (from The AUR PKGBUILD file) is
mostly wrong:
depends=('file' 'fftw' 'fluidsy
On Sun, 10 Dec 2017 11:25:26 +0100, Ralf Mardorf wrote:
>Off-topic:
>
>On Sun, 10 Dec 2017 10:51:43 +0100, Filipe Coelho wrote:
>>In case you did not notice from me and Rui, we Portuguese people like
>>to support as much stuff as possible :)
>
>Not really. For example, record a few audio tracks w
Off-topic:
On Sun, 10 Dec 2017 10:51:43 +0100, Filipe Coelho wrote:
>In case you did not notice from me and Rui, we Portuguese people like
>to support as much stuff as possible :)
Not really. For example, record a few audio tracks with Qtractor using
a low frame size, while you mute several track
On 10.12.2017 10:28, Ralf Mardorf wrote:
On Sun, 10 Dec 2017 09:33:25 +0100, Filipe Coelho wrote:
On 10.12.2017 00:21, Ralf Mardorf wrote:
On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote:
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull
On Sun, 10 Dec 2017 09:33:25 +0100, Filipe Coelho wrote:
>On 10.12.2017 00:21, Ralf Mardorf wrote:
>> On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote:
>>> But when installing jalv or qtractor for archlinux, because they
>>> depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.
>> su
On 10.12.2017 00:21, Ralf Mardorf wrote:
On Sat, 9 Dec 2017 18:00:32 +0100, Filipe Coelho wrote:
But when installing jalv or qtractor for archlinux, because they
depend on suil, expect it to pull gtk2, gtk3, qt4 and qt5.
suil comes with a dedicated version itself and as far as I notice
doesn't
28 matches
Mail list logo
