9 Apr
2015
9 Apr
'15
8:20 a.m.
[excuse for continuing top-posting]
Mark McCurry (current zynaddsubfx maintainer) is in the process of a
rewrite.
All the semaphores are gone and midi-parsing + synthesis is done
in-process
(either jack-callback or LV2-run) and GUI communication is completely
separated via OSC.
On 2015-04-09 15:00, Paul Davis wrote:
Speaking entirely personally, I think this design is
just plain nuts.
I
know there are some JACK-ecosystem developers who disagree with me,
but I
think that using JACK clients for this purpose is just wrong and is
pushing
the design scope for JACK.
What you're doing is precisely what a plugin architecture was
intended to
address, and I really think you'd be better off implementing your own
audio
graph with plugins. Of course, that requires a version of zyn that
can run
as a plugin, which I think has been discussed but I don't think it
was
every implemented fully.
On Thu, Apr 9, 2015 at 2:01 AM, Johannes Lorenz
<johannes89(a)mailueberfall.de
wrote:
> Hi,
>
> > I try to understand your plan:
> >
> > simple data flow example:
> >
> > zynaddsubfx_1_output
> >
> > V
> > sequencer_client_1_input
> >
> > V
> > sequencer_input_ringbuffer
> >
> > V
> > (sequencer processing stuff)
> >
> > V
> > sequencer_output_ringbuffer
> >
> > V
> > sequencer_client_output
> >
> > V
> > system_client_input(hardware output)
>
> Your picture is indeed correct. To add some more examples:
>
> * Something like this is also possible
>
> sequencer_input_ringbuffer_1
> sequencer_input_ringbuffer_2
> V V
> plus (i.e. addition of sound-waves)
> V
> plus_effect_ringbuffer
>
> * The part that you labeled "(sequencer processing stuff)" might
> be
> filled with:
>
> V
> peak_controller_effect some lfo generator
> V (lfo) V (lfo)
> zynaddsubfx_2_volume_input
> zynaddsubfx_2_filter_freq_input
> V
> (zynaddsubfx_2)
> V
> zynaddsubfx_2_output
> V
> sequencer_client_2_input
> V
>
> > Maybe also what you envision to happen in which thread or which
> > callback?
>
> Let's take the second example. zynaddsubfx itself is in another
> process,
> so we don't need to run this at all. For feeding each ringbuffer
> from zyn,
> I planned to use a separate jack client. E.g., if process() of
> sequencer_client_1_input is being called, it simply copies "nframes"
> into
> sequencer_input_ringbuffer.
>
> Everything that now remains (e.g. lfo generator,
> peak_controller_effect,
> sending input to zynaddsubfx_2) is done by a process() callback of
> sequencer_client_output. I call this one the master jack client.
>
> About the problem:
>
> A point where I think spinlocks can't be avoided would be, e.g.,
> reading
> from sequencer_output_ringbuffer. The sequencer's master jack client
> would
> need to do that in process(), but it can not guess when the
> ringbuffer
> reader from sequencer_client_2_input has even started to feed the
> ringbuffer.
>
> > Do you want to do some signal processing in your sequencer or
> would it
> > be ok to delegate this to other jack clients? (may be easier)
>
> Hopefully you got it from the explenations above: the master jack
> client
> would do this right now, as I planned. Other ideas will be fine,
> too.
> Though, I guess, for "some lfo generator", e.g., a separate jack
> client
> would be overkill, as this generator simply does, e.g., f(x) =
> sin(x).
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel(a)lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>