LV2 Instruments in Ardour3beta5

Installation & Configuration Mac OS X
#1

Hello,

I’m interested in this topic because I plan to develop some LV2 instruments using the Faust DSP language. I understand that only Ardour3 will support LV2. In beta 5, I seem to be able to record audio, record MIDI notes, and to run AU audio plugins.

However, when I try to add the LV2 example synthesizer to a track from the tracks and busses window, I get “[ERROR]: LV2: Failed to instantiate plugin http://lv2plug.in/plugins/eg-synth” I have tried using a few different kinds of tracks with this.
(Note: The Faust instruments I compiled are showing up in this menu successfully.)

Alternatively, if when creating a track I choose Instrument: Example Sampler (I’m not sure why example synthesizer isn’t there, but all of the Faust instruments are also showing up in the menu), then Ardour crashes, and I am pasting in the crash log below.

Finally, I just want to note that LV2 and lilv (do I need that?) seem to install just fine in OS X. All the dependencies are satisfied when it compiles, and for example LV2 installs into /usr/lib/lv2 and /usr/include/lv2 (and a few other places e.g. /usr/lib/pkgconfig/). I believe that lilv probably winds up in the same place (as long as I use --prefix=/usr when configuring both of these packages …)

Cheers,
John

Process: Ardour3.bin [15129]
Path: /Applications/Ardour3beta5.app/Contents/MacOS/Ardour3.bin
Identifier: org.ardour.Ardour3
Version: 3.0/13072 (3.0/13072)
Code Type: X86 (Native)
Parent Process: launchd [133]
User ID: 501

Date/Time: 2012-11-25 10:50:45.755 -0800
OS Version: Mac OS X 10.8.2 (12C60)
Report Version: 10

Interval Since Last Report: 895603 sec
Crashes Since Last Report: 20
Per-App Interval Since Last Report: 11081 sec
Per-App Crashes Since Last Report: 8
Anonymous UUID: C53CDC10-66AE-7C4E-2E8E-CE4AFED25FC4

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

VM Regions Near 0:
–> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] —/--- SM=NUL /Applications/Ardour3beta5.app/Contents/MacOS/Ardour3.bin
__TEXT 0000000000001000-0000000000b66000 [ 11.4M] r-x/rwx SM=COW /Applications/Ardour3beta5.app/Contents/MacOS/Ardour3.bin

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 Ardour3.bin 0x00713819 boost::shared_ptrARDOUR::Plugin::operator->() const + 15
1 libardour.dylib 0x0d807160 ARDOUR::PluginInsert::private_can_support_io_configuration(ARDOUR::ChanCount const&, ARDOUR::ChanCount&) const + 34
2 libardour.dylib 0x0d807abe ARDOUR::PluginInsert::can_support_io_configuration(ARDOUR::ChanCount const&, ARDOUR::ChanCount&) const + 38
3 libardour.dylib 0x0d85d183 ARDOUR::Route::try_configure_processors_unlocked(ARDOUR::ChanCount, ARDOUR::Route::ProcessorStreams*) + 1123
4 libardour.dylib 0x0d85d8f3 ARDOUR::Route::configure_processors_unlocked(ARDOUR::Route::ProcessorStreams*) + 197
5 libardour.dylib 0x0d86a9d4 ARDOUR::Route::add_processor(boost::shared_ptrARDOUR::Processor, boost::shared_ptrARDOUR::Processor, ARDOUR::Route::ProcessorStreams*, bool) + 1450
6 libardour.dylib 0x0d86b535 ARDOUR::Route::add_processor(boost::shared_ptrARDOUR::Processor, ARDOUR::Placement, ARDOUR::Route::ProcessorStreams*, bool) + 99
7 libardour.dylib 0x0d89bd3f ARDOUR::Session::new_midi_track(ARDOUR::ChanCount const&, ARDOUR::ChanCount const&, boost::shared_ptrARDOUR::PluginInfo, ARDOUR::TrackMode, ARDOUR::RouteGroup*, unsigned int, std::string) + 3525
8 Ardour3.bin 0x0002d296 ARDOUR_UI::session_add_mixed_track(ARDOUR::ChanCount const&, ARDOUR::ChanCount const&, ARDOUR::RouteGroup*, unsigned int, std::string const&, boost::shared_ptrARDOUR::PluginInfo) + 244
9 Ardour3.bin 0x0002e3ff ARDOUR_UI::add_route(Gtk::Window*) + 1363
10 Ardour3.bin 0x005f4e02 sigc::bound_mem_functor1<void, ARDOUR_UI, Gtk::Window*>::operator()(Gtk::Window* const&) const + 96
11 Ardour3.bin 0x005f4e1f sigc::adaptor_functor<sigc::bound_mem_functor1<void, ARDOUR_UI, Gtk::Window*> >::deduce_result_type<Gtk::Window*&, void, void, void, void, void, void>::type sigc::adaptor_functor<sigc::bound_mem_functor1<void, ARDOUR_UI, Gtk::Window*> >::operator()Gtk::Window*&(Gtk::Window*&) const + 27
12 Ardour3.bin 0x005f4e48 sigc::bind_functor<-1, sigc::bound_mem_functor1<void, ARDOUR_UI, Gtk::Window*>, Gtk::Window*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()() + 38
13 Ardour3.bin 0x005f4e64 sigc::internal::slot_call0<sigc::bind_functor<-1, sigc::bound_mem_functor1<void, ARDOUR_UI, Gtk::Window*>, Gtk::Window*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, void>::call_it(sigc::internal::slot_rep*) + 26
14 libglibmm-2.4.1.dylib 0x14fb6a32 Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) + 58
15 libgobject-2.0.0.dylib 0x1500333a g_closure_invoke + 216
16 libgobject-2.0.0.dylib 0x15012a6a signal_emit_unlocked_R + 1832
17 libgobject-2.0.0.dylib 0x15013f3d g_signal_emit_valist + 2779
18 libgobject-2.0.0.dylib 0x15014309 g_signal_emit + 41
19 libgtk-quartz-2.0.0.dylib 0x15188dd3 gtk_action_activate + 259
20 libgobject-2.0.0.dylib 0x15003556 _g_closure_invoke_va + 231
21 libgobject-2.0.0.dylib 0x15013730 g_signal_emit_valist + 718
22 libgobject-2.0.0.dylib 0x15014309 g_signal_emit + 41
23 libgtk-quartz-2.0.0.dylib 0x152752ae gtk_menu_item_activate + 118
24 libgtkmm2ext.dylib 0x133c8df7 idle_call_activate(void*) + 17
25 libglib-2.0.0.dylib 0x15085a15 g_main_dispatch + 290
26 libglib-2.0.0.dylib 0x15087bbb g_main_context_iterate + 552
27 libglib-2.0.0.dylib 0x15087cfe g_main_loop_run + 251
28 libgtk-quartz-2.0.0.dylib 0x1526263e gtk_main + 174
29 libgtkmm-2.4.1.dylib 0x1598edc4 Gtk::Main::run() + 26
30 libgtkmm2ext.dylib 0x1339ff0d Gtkmm2ext::UI::run(Receiver&) + 449
31 Ardour3.bin 0x00298c1e main + 1366
32 Ardour3.bin 0x0000303e _start + 216
33 Ardour3.bin 0x00002f65 start + 41

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x974aa9ae kevent + 10
1 libdispatch.dylib 0x97c8ac71 _dispatch_mgr_invoke + 993
2 libdispatch.dylib 0x97c8a7a9 _dispatch_mgr_thread + 53

Thread 2:
0 libsystem_kernel.dylib 0x974a98e2 __psynch_cvwait + 10
1 libsystem_c.dylib 0x948d8289 _pthread_cond_wait + 938
2 libsystem_c.dylib 0x94965afc pthread_cond_wait + 48
3 libglib-2.0.0.dylib 0x150d33b2 g_cond_wait + 48
4 libardour.dylib 0x0d8f68b8 peak_thread_work() + 218
5 Ardour3.bin 0x007e57af sigc::pointer_functor0::operator()() const + 13
6 Ardour3.bin 0x007e57c6 sigc::adaptor_functor<sigc::pointer_functor0 >::operator()() const + 20
7 Ardour3.bin 0x007e57e2 sigc::internal::slot_call0<sigc::pointer_functor0, void>::call_it(sigc::internal::slot_rep*) + 26
8 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
9 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
10 libsystem_c.dylib 0x948d3557 _pthread_start + 344
11 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 3:
0 libsystem_kernel.dylib 0x974a98e2 __psynch_cvwait + 10
1 libsystem_c.dylib 0x948d8289 _pthread_cond_wait + 938
2 libsystem_c.dylib 0x94965afc pthread_cond_wait + 48
3 libglib-2.0.0.dylib 0x150d33b2 g_cond_wait + 48
4 libardour.dylib 0x0d8f68b8 peak_thread_work() + 218
5 Ardour3.bin 0x007e57af sigc::pointer_functor0::operator()() const + 13
6 Ardour3.bin 0x007e57c6 sigc::adaptor_functor<sigc::pointer_functor0 >::operator()() const + 20
7 Ardour3.bin 0x007e57e2 sigc::internal::slot_call0<sigc::pointer_functor0, void>::call_it(sigc::internal::slot_rep*) + 26
8 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
9 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
10 libsystem_c.dylib 0x948d3557 _pthread_start + 344
11 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 4:
0 libsystem_kernel.dylib 0x974a98e2 __psynch_cvwait + 10
1 libsystem_c.dylib 0x948d8289 _pthread_cond_wait + 938
2 libsystem_c.dylib 0x94965afc pthread_cond_wait + 48
3 libglib-2.0.0.dylib 0x150d33b2 g_cond_wait + 48
4 libardour.dylib 0x0d6c3d16 ARDOUR::Analyser::work() + 218
5 libardour.dylib 0x0d6c3e8b analyser_work() + 11
6 Ardour3.bin 0x007e57af sigc::pointer_functor0::operator()() const + 13
7 Ardour3.bin 0x007e57c6 sigc::adaptor_functor<sigc::pointer_functor0 >::operator()() const + 20
8 Ardour3.bin 0x007e57e2 sigc::internal::slot_call0<sigc::pointer_functor0, void>::call_it(sigc::internal::slot_rep*) + 26
9 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
10 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
11 libsystem_c.dylib 0x948d3557 _pthread_start + 344
12 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 5:
0 libsystem_kernel.dylib 0x974a98e2 __psynch_cvwait + 10
1 libsystem_c.dylib 0x948d8289 _pthread_cond_wait + 938
2 libsystem_c.dylib 0x94965afc pthread_cond_wait + 48
3 libgdk-quartz-2.0.0.dylib 0x155f5af4 select_thread_func + 144
4 libsystem_c.dylib 0x948d3557 _pthread_start + 344
5 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 6:
0 libsystem_kernel.dylib 0x974a98e2 __psynch_cvwait + 10
1 libsystem_c.dylib 0x948d8289 _pthread_cond_wait + 938
2 libsystem_c.dylib 0x94965afc pthread_cond_wait + 48
3 libjack.0.dylib 0x1621afa9 Jack::JackProcessSync::Wait() + 185
4 libjack.0.dylib 0x16219807 Jack::JackMessageBuffer::Execute() + 151
5 libjack.0.dylib 0x1621a94c Jack::JackPosixThread::ThreadHandler(void*) + 172
6 libsystem_c.dylib 0x948d3557 _pthread_start + 344
7 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 7:
0 libsystem_kernel.dylib 0x974a9b06 __read_nocancel + 10
1 libjack.0.dylib 0x16220b80 Jack::JackClientSocket::Read(void*, int) + 48
2 libjack.0.dylib 0x1621ba2c Jack::JackSocketClientChannel::Execute() + 108
3 libjack.0.dylib 0x1621a94c Jack::JackPosixThread::ThreadHandler(void*) + 172
4 libsystem_c.dylib 0x948d3557 _pthread_start + 344
5 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 8:
0 libsystem_kernel.dylib 0x974a7826 semaphore_timedwait_trap + 10
1 libjack.0.dylib 0x16213338 Jack::JackMachSemaphore::TimedWait(long) + 136
2 libjack.0.dylib 0x16212943 Jack::JackConnectionManager::SuspendRefNum(Jack::JackClientControl*, Jack::JackMachSemaphore*, Jack::JackClientTiming*, long) + 35
3 libjack.0.dylib 0x16208747 Jack::JackGraphManager::SuspendRefNum(Jack::JackClientControl*, Jack::JackMachSemaphore*, long) + 71
4 libjack.0.dylib 0x1620b6d7 Jack::JackClient::CycleWait() + 71
5 libardour.dylib 0x0d6ef512 ARDOUR::AudioEngine::process_thread() + 128
6 libardour.dylib 0x0d6ef56b ARDOUR::AudioEngine::_process_thread(void*) + 17
7 libjack.0.dylib 0x1620bdf8 Jack::JackClient::Execute() + 168
8 libjack.0.dylib 0x1621a94c Jack::JackPosixThread::ThreadHandler(void*) + 172
9 libsystem_c.dylib 0x948d3557 _pthread_start + 344
10 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 9:
0 libsystem_kernel.dylib 0x974a9802 __poll_nocancel + 10
1 libardour.dylib 0x0d7205dd ARDOUR::Butler::thread_work() + 121
2 libardour.dylib 0x0d721447 ARDOUR::Butler::_thread_work(void*) + 175
3 libpbd.dylib 0x141f2530 fake_thread_start(void*) + 96
4 libsystem_c.dylib 0x948d3557 _pthread_start + 344
5 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 10:
0 libsystem_kernel.dylib 0x974a9c02 __select_nocancel + 10
1 libsystem_kernel.dylib 0x974a867f select + 92
2 libglib-2.0.0.dylib 0x15096f2e g_poll + 258
3 libglib-2.0.0.dylib 0x15087b13 g_main_context_iterate + 384
4 libglib-2.0.0.dylib 0x15087cfe g_main_loop_run + 251
5 libpbd.dylib 0x141e56ee BaseUI::main_thread() + 662
6 libpbd.dylib 0x141febbf sigc::bound_mem_functor0<void, BaseUI>::operator()() const + 87
7 libpbd.dylib 0x141febd6 sigc::adaptor_functor<sigc::bound_mem_functor0<void, BaseUI> >::operator()() const + 20
8 libpbd.dylib 0x141febf2 sigc::internal::slot_call0<sigc::bound_mem_functor0<void, BaseUI>, void>::call_it(sigc::internal::slot_rep*) + 26
9 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
10 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
11 libsystem_c.dylib 0x948d3557 _pthread_start + 344
12 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 11:
0 libsystem_kernel.dylib 0x974a78e6 mach_wait_until + 10
1 libsystem_c.dylib 0x94964c1c nanosleep + 375
2 libglib-2.0.0.dylib 0x150b1bbc g_usleep + 105
3 libardour.dylib 0x0d6ed5cc ARDOUR::AudioEngine::meter_thread() + 56
4 libardour.dylib 0x0d960c64 boost::_mfi::mf0<void, ARDOUR::AudioEngine>::operator()(ARDOUR::AudioEngine*) const + 70
5 libardour.dylib 0x0d960f8a void boost::_bi::list1<boost::_bi::valueARDOUR::AudioEngine* >::operator()<boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf0<void, ARDOUR::AudioEngine>&, boost::_bi::list0&, int) + 58
6 libardour.dylib 0x0d960fcd boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::valueARDOUR::AudioEngine* > >::operator()() + 61
7 libardour.dylib 0x0d960fe1 sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::valueARDOUR::AudioEngine* > > >::operator()() const + 17
8 libardour.dylib 0x0d960ffe sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AudioEngine>, boost::_bi::list1<boost::_bi::valueARDOUR::AudioEngine* > >, void>::call_it(sigc::internal::slot_rep*) + 26
9 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
10 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
11 libsystem_c.dylib 0x948d3557 _pthread_start + 344
12 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 12:
0 libsystem_kernel.dylib 0x974a78e6 mach_wait_until + 10
1 libsystem_c.dylib 0x94964c1c nanosleep + 375
2 libsystem_c.dylib 0x94964a46 usleep + 60
3 libardour.dylib 0x0d718344 ARDOUR::AutomationWatch::thread() + 20
4 libardour.dylib 0x0d97c86c boost::_mfi::mf0<void, ARDOUR::AutomationWatch>::operator()(ARDOUR::AutomationWatch*) const + 70
5 libardour.dylib 0x0d97cb84 void boost::_bi::list1<boost::_bi::valueARDOUR::AutomationWatch* >::operator()<boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>&, boost::_bi::list0&, int) + 58
6 libardour.dylib 0x0d97cbc7 boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::valueARDOUR::AutomationWatch* > >::operator()() + 61
7 libardour.dylib 0x0d97cbdb sigc::adaptor_functor<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::valueARDOUR::AutomationWatch* > > >::operator()() const + 17
8 libardour.dylib 0x0d97cbf8 sigc::internal::slot_call0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, ARDOUR::AutomationWatch>, boost::_bi::list1<boost::_bi::valueARDOUR::AutomationWatch* > >, void>::call_it(sigc::internal::slot_rep*) + 26
9 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
10 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
11 libsystem_c.dylib 0x948d3557 _pthread_start + 344
12 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 13:
0 libsystem_kernel.dylib 0x974a780e semaphore_wait_trap + 10
1 libardour.dylib 0x0db1338b PBD::Semaphore::wait() + 19
2 libardour.dylib 0x0d918993 ARDOUR::Worker::run() + 43
3 libardour.dylib 0x0db134f1 sigc::bound_mem_functor0<void, ARDOUR::Worker>::operator()() const + 87
4 libardour.dylib 0x0db13508 sigc::adaptor_functor<sigc::bound_mem_functor0<void, ARDOUR::Worker> >::operator()() const + 20
5 libardour.dylib 0x0db13524 sigc::internal::slot_call0<sigc::bound_mem_functor0<void, ARDOUR::Worker>, void>::call_it(sigc::internal::slot_rep*) + 26
6 libglibmm-2.4.1.dylib 0x14faa145 call_thread_entry_slot + 63
7 libglib-2.0.0.dylib 0x150b074d g_thread_proxy + 102
8 libsystem_c.dylib 0x948d3557 _pthread_start + 344
9 libsystem_c.dylib 0x948bdcee thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x00713816 ecx: 0x0d807a98 edx: 0x00000000
edi: 0x00000000 esi: 0x00000000 ebp: 0xbfffe7c8 esp: 0xbfffe7b0
ss: 0x00000023 efl: 0x00210282 eip: 0x00713819 cs: 0x0000001b
ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f
cr2: 0x00000000
Logical CPU: 0

EDIT: Edited out the binary image info from the crashlog so it would actually show up hopefully…

#2

A couple of comments on your comments:)

o when compiling using waf, always set --prefix=/usr. Otherwise, it gets really confusing if some dependencies are stored in /usr/local and others in /usr/. Some of the packages were by default looking in /usr

I would really recommend against this. /usr should be managed by the system only, there are MANY other ways to address this that work very well and don’t endanger your system if you ever have to manually remove it.

o Maybe try using homebrew instead of mac ports. I heard from one colleague in person that mac ports is "outdated." This didn't correspond to what I read on wikipedia, so I tried "mac ports" on my system. But it installs into /opt/local, which is not what the linux packages expect. So, to compile each package, you will have to completely re-do all of the paths. It's really a pain because some things are compiled with Cmake, others with waf, and others with just bare makefiles. You really will spend all day doing this.

While I will agree with the avoid macports part, it is for a far different reason, which is that if you intend to distribute the binaries you compile macports tends to break things in dependencies in very strange ways, thus why we don’t use it when compiling Ardour on OS X.

That being said I will also say I have been impressed with Homebrew, if it is limited in the number of packages, but I do prefer it’s method of package mangement in some ways for instance. (Install into it’s own folder, and just symlink to the appropriate files) That being said, I would recommend not using it for building a distributed binary.

Without googling, your Qt issue seems to be related to your X11 build environment, which to be honest you shouldn’t be using X11 for Qt on OS X unless you KNOW you need it. You should be compiling to a Quartz backend, not X11.

o Of course, still there were other problems (getting it to find boost even though I have it installed and figuring out how to edit the the cmake-generated files). I get impatient after spending 5 hours working on something and still having no idea how long it will take to finish it. I have other work to get done too.

Environment Variables are your friend, I don’t know of any commonly used build system that doesn’t respect it (Well scons can ignore them, but that is a complex topic and to be ignored here for the moment;)

   Seablade
#3

What is your question?:slight_smile:

#4

Hello,

My apologies–I will try again. The whole thing was there in the preview, but maybe the crashlog was too long.

I’m interested in this topic because I plan to develop some LV2 instruments using the Faust DSP language. I understand that only Ardour3 will support LV2. In beta 5, I seem to be able to record audio, record MIDI notes, and to run AU audio plugins.

However, when I try to add the LV2 example synthesizer to a track from the tracks and busses window, I get “[ERROR]: LV2: Failed to instantiate plugin http://lv2plug.in/plugins/eg-synth” I have tried using a few different kinds of tracks with this.
(Note: The Faust instruments I compiled are showing up in this menu successfully.)

Alternatively, if when creating a track I choose Instrument: Example Sampler (I’m not sure why example synthesizer isn’t there, but all of the Faust-compiled LV2 instruments are also showing up in the menu), then Ardour crashes (Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000)

Finally, I just want to note that LV2 and lilv (do I need that one?) seem to install just fine in OS X. All the dependencies are satisfied when it compiles, and for example LV2 installs into /usr/lib/lv2 and /usr/include/lv2 (and a few other places e.g. /usr/lib/pkgconfig/).

Cheers,
John

#5

And here is the crashlog:

PS. Maybe I should mention I am running Mountain Lion.

#6

@johnreed

OS X of A3 has not been thoroughly tested, it is far more than likely you are running into a bug in A3’s code, can you check with other LV2 instruments?

     Seablade

PS: Ardour2 does support LV2, but not on OS X and not with Virtual Instruments as it would make little sense given that A2 doesn’t support MIDI.

#7

Thanks for your response. Just to re-iterate, I have the LV2 plug-ins compiling from Faust, which isn’t too much trouble to setup (hint: install pure from source instead of using any packages – it will take a while for llvm dependency to compile), but it seems to be a lot of trouble to use them on OS X. I think I will just wait until Ardour works for this for OS X. Should I try building Ardour 3 from SVN – is that necessary to get LV2 support working?

In general though, I have to comment that maybe someone needs to step up to the plate to maintain all the LV2 stuff for Mac OS X. Users should just be able to download one or two binaries to get all of the plug-ins working. If you get mac people hooked on the LV2 plug-ins, then you are going to have a lot more users.

PS. I tried for about five hours to compile several other sets of LV2 plug-ins in OS X. I have tips for other people if they ever try to manually compile LV2 plugins for OS X:
o Start off without installing QT and see if maybe you can get the stuff built using GTK only. (I don’t know if this is possible – but it will probably save you a lot of trouble.)
o when compiling using waf, always set --prefix=/usr. Otherwise, it gets really confusing if some dependencies are stored in /usr/local and others in /usr/. Some of the packages were by default looking in /usr
o Maybe try using homebrew instead of mac ports. I heard from one colleague in person that mac ports is “outdated.” This didn’t correspond to what I read on wikipedia, so I tried “mac ports” on my system. But it installs into /opt/local, which is not what the linux packages expect. So, to compile each package, you will have to completely re-do all of the paths. It’s really a pain because some things are compiled with Cmake, others with waf, and others with just bare makefiles. You really will spend all day doing this.
o Also at least one of the dependencies though my version of QT was too old, but actually it was wrong.
o Even when you get past that, there will be errors like the following:
[ 6/13] cxx: src/qt4_in_gtk2.cpp -> build/src/qt4_in_gtk2.cpp.4.o
In file included from /opt/local/include/QtGui/QX11EmbedContainer:1,
from …/src/gtk2_in_qt4.cpp:17:
/opt/local/include/QtGui/qx11embed_x11.h:77: error: ‘XEvent’ has not been declared
/opt/local/include/QtGui/qx11embed_x11.h:115: error: ‘XEvent’ has not been declared
In file included from /opt/local/include/QtGui/QX11EmbedWidget:1,
from …/src/qt4_in_gtk2.cpp:20:
/opt/local/include/QtGui/qx11embed_x11.h:77: error: ‘XEvent’ has not been declared
/opt/local/include/QtGui/qx11embed_x11.h:115: error: ‘XEvent’ has not been declared

You can google around for this, but I think you might have to edit the source code to fix it, or else somehow eliminate the QT-dependencies.

o Of course, still there were other problems (getting it to find boost even though I have it installed and figuring out how to edit the the cmake-generated files). I get impatient after spending 5 hours working on something and still having no idea how long it will take to finish it. I have other work to get done too.

#8

Hi,

Thanks again for your response. I can tell you have more experience in this sort of stuff than I do. You could well be right about whatever the backend of QT ought to be–I was just using the defaults generated by ./waf configure. For me, it was just easier to edit the wscript files to disable QT altogether and build on GTK. I didn’t find a documented way to do this directly from the command line for waf, but I got tired for searching about it after I figured out how to do it by editing wscript.

Cheers,
John

#9

Agreed on all point of course, and didn’t mean to imply anything in your choice of not using LV2 on Mac, it is your choice and I fully understand why you made it as well, nothing bad there to me:)

   Seablade
#10

@seablade: I don’t think there’s anything I disagree with there - I realise it would make your particular workflow better if you could port sessions between Mac / linux etc using the same plugins (from my point of view, and this relates only to my own software - the time / work involved in porting a plugin to LV2 on Mac would be almost the same (or perhaps counter-intuitively, more work, than porting it to AU or Mac VST - and for a much smaller potential market) - the principle reason for this is that whatever the underlying plugin API, there is almost always the need to construct / port a new GUI engine (in the case of Mac it meant moving to Obj C, so yet another language too…) This has now been done for AU which means I have a framework in place to port more plugins relatively easily.
(But this is getting a long way from the original topic… My recommendation to @johnreed was just to consider if LV2 was the best option on the Mac or whether there might be more complete solutions available with other formats, for the same investment in developer time - obviously that applies differently if the primary purpose was to get more existing LV2 plugins working for Mac).

#11

@seablade: I didn’t mean to (and I hope I didn’t) imply that it would be a bad thing to do LV2 on Mac, I take your point about (session) portability, I was just looking at it partly from my own experience - which (as a commercial developer) means that I have no plans to ever do LV2 plugins on anything other than linux as it will most likely always be an Ardour / Mixbus only format on any other OS, and Ardour / Mixbus already supports more common native formats on those other platforms - together with all the other DAWs (which makes developing for native formats more attractive than targeting a format that would be limited to only the minority DAW on those platforms).
(The small amount of evidence I have is that the case for session portability between ardour / mixbus on different OS is far less of an issue - except to a very small number of users - than for example being able to move sessions between Ardour and e.g. Pro-Tools etc - which will always be difficult for many reasons).
(From a purely technical standpoint, I’d argue there is almost no reason for LV2 to exist on the Mac, as AU is architecturally very similar, and more complete - I don’t think there is anything that LV2 would allow you to do that you can’t already do with AU).

#12

Heh lemme respond in chunks:)

@seablade: I didn't mean to (and I hope I didn't) imply that it would be a bad thing to do LV2 on Mac, I take your point about (session) portability, I was just looking at it partly from my own experience - which (as a commercial developer) means that I have no plans to ever do LV2 on anything other than linux as it will most likely always be an Ardour / Mixbus only format on any other OS, and Ardour / Mixbus already supports more common native formats on those other platforms - together with all the other DAWs (which makes developing for native formats more attractive than targeting a format that would be limited to only the minority DAW on those platforms).

Yes there were other things I personally disagreed with, but to be honest I don’t have your experience as a commercial developer for plugins so I wasn’t going to even try as I also know you are most likely correct in regards to any technical issue even if I disagree on other grounds(And even then might still be wrong:)

I won’t disagree that right now it certainly seems like LV2 is going to be limited to Linux and Ardour/Mixbus, but I also believe that the only way to change that would be to make it available and give reason to use it.

(The small amount of evidence I have is that the case for session portability between ardour / mixbus on different OS is far less of an issue - except to a very small number of users - than for example being able to move sessions between Ardour and e.g. Pro-Tools etc - which will always be difficult for many reasons).

Yep I think it is a given that the amount of users on Linux to start with is pretty small, and especially the amount of users that use BOTH Linux and Mac, and for audio production even more, is tiny.

That being said, again, this only to me points even more to the need to make session compatibility strong, as if anyone on Mac wanted to try Linux they wouldn’t be able to go back and forth, they couldn’t try and get used to tools on a Mac and make their transition to Linux easier (How easy it is is a different topic), as they already know the tools, and know they can continue their work on Linux without issues, etc. Yes it is only one of many possible ways to think about something, and my goal isn’t to force Linux on people that don’t want it, but rather to provide the option for it for people that do want it. And I think providing session compatibility cross platform is a strong argument in it’s favor.

(From a purely technical standpoint, I'd argue there is almost no reason for LV2 to exist on the Mac, as AU is architecturally very similar, and more complete - I don't think there is anything that LV2 would allow you to do that you can't already do with AU).

Except the possibility to take that session that you are working on, on your mac laptop, and take it to your primary production machine to continue mixing it, without have to redo all your plugins and automation on said plugins;) Other than that though I completely agree.

I will also reiterate that my workflow is reflectant (oh look I made a new word;) of a tiny minority of users I certainly agree. But I know I have already mentioned to you in the past when you started Overtone that I was looking forward to the day I could use your plugins on a session on my laptop, then go to my workstation and keep working on it, without losing data. To me LV2 support on Mac is a large step in that direction.

  Seablade

PS: It is actually surprising, leaving the commercial world for a moment, but the free (As in beer) plugins on Linux actually outweighs OS X thus far in my experience. For instance I spent some time looking for a simple, but decent quality, gate plugin for OS X I could tell my students to go grab and put on the lab computers here so that they could work on sessions at their home as well as in the lab. I couldn’t find one that was acceptable or comparable to the options on Linux. I have been exceedingly tempted to grab the LADSPA SWH plugins for instance and put them on their machines but haven’t for the sake of trying to keep things simple. Good luck if you want to find a true downwards expander that works on recent OS X releases:) But if we followed the same philosophy of, why bother AU is fine, then even LADSPA wouldn’t be an option on OS X and my students really would be SOL.

#13

@linuxdsp

I could be wrong but I don’t think his/her intention was to build a new plugin, but rather first to port existing LV2 plugins to Mac to make them available there, which broadens the reach of LV2, and personally I wouldn’t complain myself as it means sessions done on Ardour/Mixbus on OS X are likely to be more portable to Linux which is a particular workflow I am interested in. Along with this it means my students have a much wider array of plugins to work on their work with in Ardour or Mixbus, and they don’t have to be as concerned with, is this plugin on both machines I work on or not.

So personally I can see this being a good thing, but I don’t have time to spend on it personally;)

  Seablade
#14

I think your starting from the wrong point - if you are building plugins on the Mac, it makes much more sense to start from ‘I need to build an AudioUnit plugin’ rather than ‘How do I build an LV2 plugin’ - and then work out how / what tools are available (I would recommend coding up the plugin properly rather than relying on rapid application development kits - which is essentially what Faust pd etc are - If you’re going to go to the trouble of learning a whole new language, then you might as well learn one like C / C++ which will normally allow you to make far more efficient / stable / easier to maintain / etc/ code).
All the AU documentation is available from the apple developer pages, and Ardour / Mixbus already supports AU (as do most other Mac audio applications). If you build an LV2 plugin then it will likely be ‘Ardour only’ - for the foreseeable future at least - whereas for a similar investment (probably less) in time and effort, you could create an AU plugin that would work on just about all other host applications including ardour.
Alternatively, if you have to use design tools which only target LV2 then I think it would be better to use them on linux - where LV2 is better supported.

#15

@johnreed

An update on this is in order. I have been working on this problem as I am working on compiling Calf for OS X. Turns out you likely may have had working plugins fine, but you likely had 64 bit plugins, and a 32 bit host if sing the distributed packages from ardour.org. I had similar crashes that were driving me crazy until I realized I had been compiling 64-bit. Sometimes it is the simple things that kill me.

Here is what I can tell you, disabling the Qt and X11 parts in suil is necessary if you have the Qt dev libs installed yes, and possibly if you have XQuartz installed, not sure on that. Have to check to see if that plays into it. Disabling it is a simple matter in the wscript, and I have sent messages to David Robillard to see what he wants me to do to best address this.

I have succesfully compiled Calf on OS X, and loaded it in a self-compiled Ardour, both 64 bits. I am working on compiling Calf for 32 bit, as how it stands right now it couldn’t be used on A2 or Mixbus on OS X, at least the distributed packages. This actually compiles fairly easily on OS X once the build stack is set up, so credit to the Calf devs. With a lot of luck this works well, but I am waiting to see. Ideally this allows the same session using either the Harrison LV2 plugins or the Calf plugins to open on both Linux and OS X and be worked on without an issue, cross platform portability is definitely part of why I am doing this.

  Seablade
#16

Progress Update:
So Calf compiled, installed, and working. But it will not work on any released version of Ardour on OS X, and it isn’t a guarantee that an update will be released for A2 to enable it. There is a small modification that has to be made to Ardour’s .app bundle in order for them to work, namely the pixmap engine has to be included. So definitely possibilities here…

Seablade