Comments (34)
kmatheussen
commented on July 22, 2024
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff60ab0dc in free () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff60ab0dc in free () from /lib64/libc.so.6
#1 0x00007ffff547e33c in DISTRHO::String::~String (this=0xbbeae0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/../extra/String.hpp:223
#2 0x00007ffff547e9de in DISTRHO::Parameter::~Parameter (this=0xbbeaa8, __in_chrg=<optimized out>) at ../../dpf/distrho/src/../DistrhoPlugin.hpp:375
#3 0x00007ffff547eaef in DISTRHO::Plugin::PrivateData::~PrivateData (this=0xbbe5a0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginInternal.hpp:137
#4 0x00007ffff547fbb3 in DISTRHO::Plugin::~Plugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPlugin.cpp:75
#5 0x00007ffff547abe2 in DISTRHO::ZamDelayPlugin::~ZamDelayPlugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ZamDelayPlugin.hpp:31
#6 0x00007ffff547abfe in DISTRHO::ZamDelayPlugin::~ZamDelayPlugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ZamDelayPlugin.hpp:31
#7 0x00007ffff547ee03 in DISTRHO::PluginExporter::~PluginExporter (this=0xbbe4f8, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginInternal.hpp:222
#8 0x00007ffff5481294 in DISTRHO::PluginVst::~PluginVst (this=0xbbe4e0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:441
#9 0x00007ffff54812bc in DISTRHO::PluginVst::~PluginVst (this=0xbbe4e0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:451
#10 0x00007ffff548280e in DISTRHO::vst_dispatcherCallback (effect=0xbbe430, opcode=1, index=0, value=0, ptr=0x0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1274
#11 0x0000000000434185 in juce::ModuleHandle::closeEffect (this=0xbb84d0, eff=0xbbe430) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:711
#12 0x00000000004357a1 in juce::VSTPluginInstance::cleanup (this=0xbbefa0) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1154
#13 0x00000000004354d0 in juce::VSTPluginInstance::~VSTPluginInstance (this=0xbbefa0, __in_chrg=<optimized out>)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1129
#14 0x00000000004356da in juce::VSTPluginInstance::~VSTPluginInstance (this=0xbbefa0, __in_chrg=<optimized out>)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1138
#15 0x00000000004575f4 in std::default_delete<juce::VSTPluginInstance>::operator() (this=0x7fffffffd8a8, __ptr=0xbbefa0) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:84
#16 0x000000000044aa62 in std::unique_ptr<juce::VSTPluginInstance, std::default_delete<juce::VSTPluginInstance> >::~unique_ptr (this=0x7fffffffd8a8, __in_chrg=<optimized out>)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:360
#17 0x0000000000418d14 in juce::VSTPluginFormat::findAllTypesForFile (this=0x7fffffffd960, results=..., fileOrIdentifier=...)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:3569
#18 0x00000000004099a5 in add_descriptions_from_plugin_file (descriptions=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:68
#19 0x0000000000409a2e in write_container_descriptions_to_cache_on_disk (container_filename=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:85
#20 0x000000000040a281 in main (argc=3, argv=0x7fffffffdce8) at ../../../audio/Juce_plugin_scanner.cpp:230
from zam-plugins.
kmatheussen
commented on July 22, 2024
If I comment out the call to 'std:free' for the above crash, ZamDelay is accepted by the scanner. However, when I try to load the plugin into Radium, I get this crash:
(gdb) bt
#0 0x00007fffeceda36a in strlen () from /lib64/libc.so.6
#1 0x00007ffff725016d in __interceptor_strlen (s=0x0) at ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:368
#2 0x00007fff6365b742 in DISTRHO::strncpy (dst=0x7fffdc4fd8b0 "", src=0x0, size=8) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:76
#3 0x00007fff6365d87c in DISTRHO::vst_dispatcherCallback (effect=0x60c00009ee00, opcode=6, index=0, value=0, ptr=0x7fffdc4fd8b0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1294
#4 0x0000000004371042 in juce::VSTPluginInstance::dispatch (this=0x61b00003f780, opcode=6, index=0, value=0, ptr=0x7fffdc4fd8b0, opt=0)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1753
#5 0x0000000004371d23 in juce::VSTPluginInstance::getTextForOpcode (this=0x61b00003f780, index=0, opcode=opcode@entry=6)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:2533
#6 0x0000000004371dd5 in juce::VSTPluginInstance::VSTParameter::getLabel (this=<optimized out>) at ../../JuceLibraryCode/modules/juce_audio_processors/processors/juce_AudioProcessorParameter.h:202
#7 0x00000000042b99d4 in operator() (__closure=0x604000a0dad0) at ../../../audio/Juce_plugins.cpp:1676
#8 std::__invoke_impl<void, get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()>&> (__f=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:60
#9 std::__invoke_r<void, get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()>&> (__fn=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:153
#10 std::_Function_handler<void(), get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:291
#11 0x00000000042b6bbe in std::function<void ()>::operator()() const (this=<optimized out>) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:248
#12 (anonymous namespace)::run_callback (arg=<optimized out>) at ../../../audio/Juce_plugins.cpp:177
#13 0x00000000044390a1 in juce::AsyncFunctionCallback::messageCallback (this=0x60d0003811e0) at ../../JuceLibraryCode/modules/juce_events/messages/juce_MessageManager.cpp:153
#14 0x0000000004439e4a in juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}::operator()(int) const (fd=6, __closure=0x61200000ff48)
at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:43
#15 std::__invoke_impl<void, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int>(std::__invoke_other, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int&&) (
__f=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:60
#16 std::__invoke_r<void, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int>(std::__is_invocable&&, (juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&)...) (__fn=...)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:153
#17 std::_Function_handler<void (int), juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}>::_M_invoke(std::_Any_data const&, int&&) (__functor=..., __args#0=<optimized out>)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:291
#18 0x0000000004437acf in std::function<void (int)>::operator()(int) const (__args#0=6, this=0x61200000ff48) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:248
#19 juce::InternalRunLoop::dispatchPendingEvents (this=0x608000004020) at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:169
#20 juce::MessageManager::dispatchNextMessageOnSystemQueue (returnIfNoPendingMessages=<optimized out>) at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:260
#21 juce::MessageManager::runDispatchLoop (this=<optimized out>) at ../../JuceLibraryCode/modules/juce_events/messages/juce_MessageManager.cpp:128
#22 0x00000000042b71db in (anonymous namespace)::JuceThread::run (this=0x613000000200) at ../../../audio/Juce_plugins.cpp:1258
#23 0x00000000043f57ed in juce::Thread::threadEntryPoint (this=0x613000000200) at ../../JuceLibraryCode/modules/juce_core/threads/juce_Thread.cpp:96
#24 0x00000000043f59f9 in juce::juce_threadEntryPoint (userData=<optimized out>) at ../../JuceLibraryCode/modules/juce_core/threads/juce_Thread.cpp:118
#25 juce::threadEntryProc (userData=<optimized out>) at ../../JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:834
#26 0x00007ffff2af2ee5 in start_thread () from /lib64/libpthread.so.0
#27 0x00007fffecf48d1d in clone () from /lib64/libc.so.6
from zam-plugins.
kmatheussen
commented on July 22, 2024
See also discussion here: https://users.notam02.no/~kjetism/radium/forum/viewtopic.php?f=7&t=279
from zam-plugins.
zamaudio
commented on July 22, 2024
@kmatheussen do you also get crashes with the rest of zam-plugins? and what about other DPF-based plugins? That would be an interesting test. I'm sorry but I don't know anything about Radium.
from zam-plugins.
zamaudio
commented on July 22, 2024
@kmatheussen from that backtrace, it looks like the host, Radium, is calling the deconstructor twice, so tries to double free the plugin. ~VSTPluginInstance() see # 13 and # 14 of the first backtrace, (somehow # 5 and # 6 are both called which are the same destructor for my plugin).
from zam-plugins.
zamaudio
commented on July 22, 2024
To compile i just wrote "make", but "make" crashed too (!):
It looks like the ttl generation failed for you, can you please post your git hash that you were on when you ran that command?
from zam-plugins.
kmatheussen
commented on July 22, 2024
do you also get crashes with the rest of zam-plugins?
No, just this one. Tried all the others.
That would be an interesting test. I'm sorry but I don't know anything about Radium.
Radium uses JUCE to host VST plugins. (Radium is probably also the oldest DAW on Linux being active developed, just so you know. :-)). Reportedly, there is currently a bug in JUCE where effOpen is called twice during init, but as far as I can see all plugins seems to manage this.
from that backtrace, it looks like the host, Radium, is calling the deconstructor twice, so tries to double free the plugin. ~VSTPluginInstance() see # 13 and # 14 of the first backtrace, (somehow # 5 and # 6 are both called which are the same destructor for my plugin).
Yes, that's really strange. It's called from DISTHRO though. Maybe @falkTX understands what happening here? It looks like DISTRHO::PluginVst::fStateChunk points to another DISTHRO::PluginVst instance. Guess there is a memory corruption happening somewhere. Have you ran the plugin with ASAN?
To compile i just wrote "make", but "make" crashed too (!):
It looks like the ttl generation failed for you, can you please post your git hash that you were on when you ran that command?
from zam-plugins.
kmatheussen
commented on July 22, 2024
Yes, that's really strange.
Oh, yes, you said, the same thing happens in frame 13 and 14 too. And that's in JUCE. This looks really strange. The destructor calls itself, with the same "this" value. And the exact same thing happens in a completely different (?) class inside DISTHRO as well. Weird.
from zam-plugins.
kmatheussen
commented on July 22, 2024
Hmm, I think frame 13 and 14 may be legit. It's some weird JUCE code that schedules deletion of the vst instance to happen in the message thread, and then waits for it to finish before exiting the scheduler. This causes the destructor to be called twice.
from zam-plugins.
kmatheussen
commented on July 22, 2024
This causes the destructor to be called twice.
No, that doesn't make sense. I guess the destructor is only called once, but the method name in the bactrace is incomplete. Frame 13 is actually called inside a "VSTDeleter" inner class inside the destructor. So I'm pretty sure there's nothing wrong with frame 13 and 14.
from zam-plugins.
zamaudio
commented on July 22, 2024
Also when it hits line 1138, it calls the destructor again ?
from zam-plugins.
kmatheussen
commented on July 22, 2024
Also when it hits line 1138, it calls the destructor again ?
Good point. I have no idea.
from zam-plugins.
kmatheussen
commented on July 22, 2024
I tried to add a call to abort() in DISTRHO::PluginVst::~PluginVst, and the ZaMaximV2, to provoke bactrace on a plugin that apparently works fine, and both the same double calls to constructrs are there as well:
(gdb) bt
#0 0x00007ffff5494877 in raise () from /lib64/libc.so.6
#1 0x00007ffff5495f68 in abort () from /lib64/libc.so.6
#2 0x00007ffff1d92281 in DISTRHO::PluginVst::~PluginVst (this=0x60c000000280, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:442
#3 0x00007ffff1d9229a in DISTRHO::PluginVst::~PluginVst (this=0x60c000000280, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:452
#4 0x00007ffff1d9435d in DISTRHO::vst_dispatcherCallback (effect=0x60c0000001c0, opcode=1, index=0, value=0, ptr=0x0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1275
#5 0x0000000000434185 in juce::ModuleHandle::closeEffect (this=0x6070000001e0, eff=0x60c0000001c0)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:711
#6 0x00000000004357a1 in juce::VSTPluginInstance::cleanup (this=0x61b000000080) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1154
#7 0x00000000004354d0 in juce::VSTPluginInstance::~VSTPluginInstance (this=0x61b000000080, __in_chrg=<optimized out>)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1129
#8 0x00000000004356da in juce::VSTPluginInstance::~VSTPluginInstance (this=0x61b000000080, __in_chrg=<optimized out>)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1138
#9 0x00000000004575f4 in std::default_delete<juce::VSTPluginInstance>::operator() (this=0x7fffffffd7a8, __ptr=0x61b000000080)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:84
#10 0x000000000044aa62 in std::unique_ptr<juce::VSTPluginInstance, std::default_delete<juce::VSTPluginInstance> >::~unique_ptr (this=0x7fffffffd7a8, __in_chrg=<optimized out>)
at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:360
#11 0x0000000000418d14 in juce::VSTPluginFormat::findAllTypesForFile (this=0x7fffffffd860, results=..., fileOrIdentifier=...)
at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:3569
#12 0x00000000004099a5 in add_descriptions_from_plugin_file (descriptions=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:68
#13 0x0000000000409a2e in write_container_descriptions_to_cache_on_disk (container_filename=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:85
#14 0x000000000040a281 in main (argc=3, argv=0x7fffffffdbe8) at ../../../audio/Juce_plugin_scanner.cpp:230
I guess backtrace in frame 13 and 14 could be fine, and that it's just bug in the backtrace. This might be the case for frame 5 and 6 as well.
from zam-plugins.
kmatheussen
commented on July 22, 2024
Anyway, I've marked ZamDelay as unstable in Radium, so the case is closed on my end. Please let me know if you need more help.
from zam-plugins.
kmatheussen
commented on July 22, 2024
In the JUCE AudioPluginHost program, none of the ZAM vst plugins are accepted by the scanner (it's not the same scanner that is used in Radium).
In Renoise, the scanner accepted ZamDelay, but ZamDelay crashes when trying to load it.
In Ardour, ZamDelay is both accepted by the scanner, and it even runs, but I get these assertion messages when deleting the plugin:
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
from zam-plugins.
zamaudio
commented on July 22, 2024
I cannot reproduce any of these assertion messages on Ardour 5.12 or Ardour 6.0 (compiled from source) on Fedora 30. Can you point me to the official JUCE test program that I can use to reproduce?
from zam-plugins.
kmatheussen
commented on July 22, 2024
wget https://github.com/juce-framework/JUCE/archive/5.4.7.tar.gz
tar xvzf 5.4.7.tar.gz
cd JUCE-5.4.7/extras/AudioPluginHost/Builds/LinuxMakefile/
make -j3
./build/AudioPluginHost
from zam-plugins.
zamaudio
commented on July 22, 2024
Thanks
from zam-plugins.
zamaudio
commented on July 22, 2024
I got this against every VST plugin in zam-plugins
assertion failure: "obj->plugin == nullptr" in file ../../dpf/distrho/src/DistrhoPluginVST.cpp, line 1251
But they all load in AudioPluginHost and delete fine.
from zam-plugins.
zamaudio
commented on July 22, 2024
That assertion is expected, because some hosts call effOpen twice, some don't .
from zam-plugins.
zamaudio
commented on July 22, 2024
from zam-plugins.
zamaudio
commented on July 22, 2024
@kmatheussen not sure what is going wrong on your end... seems all good here.
from zam-plugins.
kmatheussen
commented on July 22, 2024
Guess it behaves differently because of memory corruption. Sometimes it
works, sometimes not. And in your code, calling "effOpen" is taken care of
by DISTHRO, so that shouldn't explain the assertions.
…On Sat, May 30, 2020 at 12:17 PM Damien Zammit ***@***.***> wrote:
@kmatheussen <https://github.com/kmatheussen> not sure what is going
wrong on your end... seems all good here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#80 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3JZZ6YAZDK7KTWZ47GDRUDMJ3ANCNFSM4NMLT7CA>
.
from zam-plugins.
kmatheussen
commented on July 22, 2024
I'm compiling the plugins like this though:
[kjetil@localhost dpf]$ git diff
diff --git a/Makefile.base.mk b/Makefile.base.mk
index d8623e6..15c42f3 100644
--- a/Makefile.base.mk
+++ b/Makefile.base.mk
@@ -146,7 +146,7 @@ else
# Common linker flags
LINK_OPTS = -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-O1 -Wl,--as-needed
ifneq ($(SKIP_STRIPPING),true)
-LINK_OPTS += -Wl,--strip-all
+#LINK_OPTS += -Wl,--strip-all
endif
endif
diff --git a/Makefile.plugins.mk b/Makefile.plugins.mk
index 7c1e554..79a8e7e 100644
--- a/Makefile.plugins.mk
+++ b/Makefile.plugins.mk
@@ -21,8 +21,8 @@ include $(DPF_PATH)/Makefile.base.mk
TARGET_DIR = ../../bin
BUILD_DIR = ../../build/$(NAME)
-BUILD_C_FLAGS += -I.
-BUILD_CXX_FLAGS += -I. -I$(DPF_PATH)/distrho -I$(DPF_PATH)/dgl
+BUILD_C_FLAGS += -I. -g -O0
+BUILD_CXX_FLAGS += -I. -I$(DPF_PATH)/distrho -I$(DPF_PATH)/dgl -g -O0 #-fsanitize=address
ifeq ($(HAVE_CAIRO),true)
DGL_FLAGS += -DHAVE_CAIRO
from zam-plugins.
kmatheussen
commented on July 22, 2024
And in your code, calling "effOpen" is taken care of by DISTHRO, so that shouldn't explain the assertions.
Above it should say: "calling "effOpen" twice".
from zam-plugins.
zamaudio
commented on July 22, 2024
With -fsanitize=address commented out as above, I don't get any difference.
When I compile with that flag and install libasan, however I get this:
==510==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
make: *** [Makefile:23: gen] Error 1
from zam-plugins.
zamaudio
commented on July 22, 2024
LD_PRELOAD=/usr/lib64/libasan.so.5 AudioPluginHost seems to run the plugins fine...
from zam-plugins.
kmatheussen
commented on July 22, 2024
I was testing ardour/renoise/juce with the call to std::free commented out, as I wrote above. When I reinserted that line, the scanner in Ardour doesn't accept ZamDelay either. Could it be gcc version? I've tried both gcc 9 and gcc 10 now.
(-fsanitize=address doesn't change whether it crashes or not)
from zam-plugins.
zamaudio
commented on July 22, 2024
$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
from zam-plugins.
zamaudio
commented on July 22, 2024
Could it be something simple like make install failing to install the version you think you just compiled due to the make failing, so you might not even have the correct plugins...
from zam-plugins.
kmatheussen
commented on July 22, 2024
I'm not writing "make install", I just point the hosts to scan for
plugins in /home/kjetil/zam-plugins/bin
…On Sat, May 30, 2020 at 1:07 PM Damien Zammit ***@***.***> wrote:
Could it be something simple like make install failing to install the version you think you just compiled due to the make failing, so you might not even have the correct plugins...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
from zam-plugins.
zamaudio
commented on July 22, 2024
@kmatheussen I updated the dpf submodule and fixed some uninitialised values. Please try again on master.
from zam-plugins.
zamaudio
commented on July 22, 2024
@kmatheussen can you please test again using zam-plugins 4.1, I think the bug should be gone.
from zam-plugins.
Related Issues (20)
- ZamConvo ompile error HOT 3
- HeadX2: 48000 vs 44100 warning HOT 3
- ZaMultiComp(X2) high DSP load HOT 5
- 3.11 tries to install ladspa plugins but they aren't built HOT 1
- Cross build for ARM: Segmentation fault during ZamVerb lv2-ttl-generate HOT 2
- Segmentation Fault when booting SuperCollider Server.local with ZamTube installed HOT 3
- please consider re-ordering the changelog file showing most recent revisions at the top of the file HOT 1
- changelog updates in GitHub release messages? HOT 4
- Compiling from git fails on DPF HOT 4
- Segmentation fault using zamheadx2 with liquidsoap HOT 10
- Update to latest DPF HOT 4
- Sample rate changes HOT 2
- CLAP and VST3 and built but not installed HOT 2
- Autosat VST3: Failed to load chunk data warning on Ardour. HOT 4
- Feature request - ZaMultiCompX2 - Mono button on LF band HOT 9
- Error compile (make) "ZamHeadX2" samplerate was not found in the pkg-config HOT 2
- Unusable on Windows with Audacity (VST) HOT 2
- ZamHeadX2 array indices swapped HOT 2
- vst2 Version doesn't work right in Audacity HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zam-plugins.