Standalone sfizz using wrapper

[jpcima]

Standalone with JACK client and Editor

It's based on vst3 sample projects, namely audiohost and editorhost, which are dynamic-loading wrappers of the vst3 bundle.
For some unknown reason, sdk doesn't provide a 2-in-1 host program, so this is a large copy&paste to do just that.

Work in progress

• segfaults on exit
• selects to host in gtkmm rather than raw X11 (the latter has a crash issue, the former acts more sluggish)
• uses a search for the vst3 bundle in standard paths, and also the host program's folder, to let it run from the build
• possibly reveals an implementation bug in our vst3:
  it blocks sendMessage from our background thread, because it has a thread checker which rejects origins other than the UI thread. For example, the MIDI note events don't transfer to the visual keyboard. This maybe calls to reexamine the update model used in the processor.

[paulfd]

• it blocks sendMessage from our background thread, because it has a thread checker which rejects origins other than the UI thread. For example, the MIDI note events don't transfer to the visual keyboard. This maybe calls to reexamine the update model used in the processor.

Any reason for this limitation? Maybe the message pipe is an SPSC queue?

[jpcima]

Any reason for this limitation? Maybe the message pipe is an SPSC queue?

After researching this deeper, I arrived to the conclusion that it's probably just an unimplemented.

// TODO we should test if we are in UI main thread else postpone the message

At least one sample of vst3sdk calls sendMessage in a non-UI thread.

[redtide]

Moved and updated in sfztools/sfizz-ui#105