[LAD] Re: Update of zita-at1

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

[LAD] Re: Update of zita-at1

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

[LAD] Re: Update of zita-at1

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

[LAD] Re: Update of zita-at1

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,

Bug#967257: ardour: depends on deprecated GTK 2

. 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

Bug#967257: ardour: depends on deprecated GTK 2

. 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

Bug#967257: ardour: depends on deprecated GTK 2

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,

Bug#967257: ardour: depends on deprecated GTK 2

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,

Bug#1061203: Ardour - GTK2 removal

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

Bug#1061203: Ardour - GTK2 removal

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

Bug#967257: ardour: depends on deprecated GTK 2

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

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

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

Bug#967257: ardour: depends on deprecated GTK 2

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

Bug#1054233: LV2 plugin install path

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

Bug#1054233: LV2 plugin install path

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

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

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

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

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

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

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

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

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

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

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)

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

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: >

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

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

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

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 communit

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

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

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

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.

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

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:

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

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

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

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

Re: [LAD] Any csound experts here ?

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`

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

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:

Re: [LAD] Phase rotation

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 fa

Re: [LAD] Phase rotation

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

[LAD] Phase rotation

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

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

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:

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

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.

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

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

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

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

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

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

Re: [LAD] Freenode #lad #lau

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?

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

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

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

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

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

Re: [LAD] A question to plugin host devs

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

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

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:

Re: [LAD] BPM and key detection libraries

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

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

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.

Re: [LAD] jack meterbridge 0.9.2 update / maintenance

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

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

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

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

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

[LAD] LAC steaming to c-base, Berlin

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

Re: [LAD] Bit shift

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

Re: [music-dsp] Sound Analysis

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

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

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

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

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) -

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

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.

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

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

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

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

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

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

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

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. >>> >>

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

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

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

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

Re: [LAD] PipeWire

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

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

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

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

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

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

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 w

[LAD] Github DCMA takedown notice - VeSTige header

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

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

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)/.

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

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

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

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

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

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

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

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

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

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

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

[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:

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

Re: [LAD] OSC-generating plugin?

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?

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

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

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: >> >> >> > >

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

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

Re: [LAD] aBLETON lINK

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

Re: [LAD] aBLETON lINK

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

Re: [LAD] aBLETON lINK

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

Re: [LAD] aBLETON lINK

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

Re: Ardour 5.0

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

Re: Ardour 5.0

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

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

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

[LAD] midi bindings -- was Re: ZASFX is mean with my Qtractor XML session files

On 07/08/2016 05:26 PM, Mark D. McCurry wrote: > Last time I counted the total possible parameters given the default > number of parts/kits/voices/etc there's a bit over 6,000,000 parameters. > > Think about how big of a .ttl that would be :p > > The way that MIDI learn works is: > 1. you

Bug#829508: sordi misses sord_validate binary

Package: sordi Version: 0.14.0~dfsg0-1 Severity: important Dear Maintainer, The sordi package only contains the manual page for sord_validate but the actual binary is missing. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture:

Bug#829508: sordi misses sord_validate binary

Package: sordi Version: 0.14.0~dfsg0-1 Severity: important Dear Maintainer, The sordi package only contains the manual page for sord_validate but the actual binary is missing. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture:

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

On 06/29/2016 08:17 PM, RDP wrote: > On 28 June 2016 at 23:12, Robin Gareus <ro...@gareus.org> wrote: >> On 06/28/2016 11:39 PM, Christian Schoenebeck wrote: > >>> .. if you really want license issues to be addressed, sit down, elaborate >>> and suggest >&

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

On 06/28/2016 11:39 PM, Christian Schoenebeck wrote: > However writing such a long new license text takes a load of free time (which > is already quite limited on my side), energy, research and finally a clear > consent by the developers. I understand. I am however of the strong opinion that

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

On 06/28/2016 10:20 PM, Christian Schoenebeck wrote: > You know the terms under which LinuxSampler is released, its > clearly and prominently written on the website Sadly no, those terms as self contradictory and hence invalid. One can only assume or guess your intentions. You're on the safe

  1   2   3   4   5   6   >