On 10/31/2018 04:36 PM, Tim wrote:
> I may have found some serious mistakes in the various .rdf files:
>
And in swh-plugins.rdf they are also all like that:
To illustrate that one, here is swh-plugins.rdf 1416 port #1:
Steve Harris
Ehm... help ? Bug ?
I took the time to integrate LRDF library support into the program.
We never had lrdf enumerated controls, or lrdf preset support
(interesting, I didn't know about those presets).
Yeah I know, about 10 years late...
I had a bad feeling there were going to be 'mismatches'
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
On Tue, 30 Oct 2018 16:02:36 -0400
Tim wrote:
>But beyond that there is something else:
>The actual sound of the plugin. When users dig up an old song project
> they expect plugins that were used to a) be available and b) sound
> and operate exactly like they did before, barring minor
On 10/30/2018 01:09 AM, Hermann Meyer wrote:
Am 29.10.18 um 15:34 schrieb Robin Gareus:
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
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
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
On Mon, 29 Oct 2018 15:34:44 +0100, Robin Gareus wrote:
>Why? I've never seen someone installing/removing software while
>recording or mixing. It also sounds like a bad idea to me.
I agree that it is a bad idea, but decided yesterday not to reply to
this thread and mention that it is a bad idea,
Am 29.10.18 um 15:34 schrieb Robin Gareus:
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
On 10/29/2018 10:34 AM, Robin Gareus wrote:
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
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
On 10/29/2018 12:40 AM, Hermann Meyer wrote:
Hi Tim
On guitarix we wrap the LADSPA/LV2 plugins to our own internal plugin
format and save instructions in json format.
Downside of cached information is, that it could clash on plugin load
when the plugin have changed it's ports (updated).
Hi Tim
On guitarix we wrap the LADSPA/LV2 plugins to our own internal plugin
format and save instructions in json format.
Downside of cached information is, that it could clash on plugin load
when the plugin have changed it's ports (updated).
So when you save plugin information on your
Hi list, I'm working on version 2 of MusE's safe plugin
scanner which now creates cached text lists of all plugins
found on the system, seven formats: ladspa, dssi, dssi-vst,
LinuxVst, vst, lv2, and our own MESS).
Currently each cache file is a custom xml template describing all
the various
14 matches
Mail list logo
