Re: Core and GUI Separation

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Wed, Mar 01, 2006 at 02:39:57AM +0100, Esben Stien wrote:
> Tim Janik <timj gtk org> writes:
> 
> > the synthesis/audio core is a seperate library without any GUI
> > dependencies.  and we don't have/start a daemon for beast operation.
> 
> Beast could be that daemon; then you can start a GUI, like the routing
> view window to interface to it and connect modules.

Well, if you really want that, it should be fairly easy to implement.

The reason is that
(a) already all the API BSE exports is wrapped in a special interfacing
    layer (SFI)
(b) this interfacing layer already supports inter process communcation
    (though with pipes, you probably would need to add socket support),
    we use this to execute the scheme scripts, which spawn new processes
(c) the GUI already uses this interfacing layer (look at bstgenapi.*),
    currently for inter-thread-communcation but inter-process-
    communication would work as well (we don't call libbse directly to
    interface with the sound engine)

However, the question is: would you really want that. I've coded on
aRts for a long time with IPC client/server seperation, and in the end
the question is: what does it give to the musician?

"I want to be able to use BEAST as pure midi sequencer"

  The way to go then is to add midi output support, then you can use
  BEAST as midi sequencer. If you just ignore the fact that it also can
  do audio, you'll probably be fine.

  But on the other hand, if you write a pure midi sequencer using the
  widgets from BEAST, then in the next moment some user will come along
  and say that he wants both features combined and synchronized
  appropriately. So in the end you will need to implement a GUI which
  does both, midi and audio, anyway.

"I want to connect different synthesizers"

  Traditionally that is what JACK does, and there are quite some
  applications that do support JACK already. I think even if BEAST
  offered running as JACK-like server, then still users might prefer
  JACK, because of the application support.

  So in the end, adding "real" JACK support to BEAST may be the way to
  go.

"I want to write new apps which interface to the BEAST demon"

  They probably fall into two categories:

    * applications that are not realtime music related such as a media
      player for mp3 files

      it _is_ possible to write such applications using libbse; however
      you'll see that the code in libbse does things like scanning the
      whole mp3 file before playing to be capable of seeking it - for an
      media player that can be a problem (think big file on NFS),
      whereas for realtime audio its necessary

    * applications useful for musicians, such as wave editors

      our current strategy is to integrate them - this will mean that
      the user will have all capabilities of the BSE library and friends
      available when working with BEAST

> > with matrix editor you're referring to the piano roll widget?
> 
> Well, I mean the whole track editor along with piano roll and pattern
> editor. I think it maybe could stand on it's own legs as a standalone
> application, like seq24.
> 
> Beast is now a very integrated application; it would maybe be better
> to have it a little more modular.

IMHO, the only thing that counts for an end user is the GUI. If he can
do what he wants using the GUI available, then there will be no problem,
no matter how many processes, threads, programming languages or lines of
code were necessary to actually "implement" the functionalty.

On the other hand, if the GUI available doesn't do what the user wants,
you can have ten demons lying around, each with ten threads, on seven
different computers connected via high speed networks and smart
protocols - it won't help if the GUI doesn't do what the user wants.

So I think maybe when talking about "how you would like to use BEAST",
you maybe see that some things in the current GUI are not done the way
that gives you productivity; and this may be what we really want to
discuss here.

> The FFT scopes could maybe be a DSSI.

How about adding DSSI support to BEAST first? I'd really like to see it.

But honestly as for

- make all modules LADSPA modules
- make all scopes DSSI thingys

I see good reasons for not doing it. When we have our own formats,
communication protocol and so on, we can do with it what we want. And
you'll see that a BEAST module for instance is easier to implement and
better integrated into the BEAST GUI than a LADSPA plugin. Thats
because LADSPA is a lowest common denominator standard.

The same probably goes for scopes.

But of I am all for interoperability. BEAST synths could be embedded
into other apps using DSSI. BEAST could embed other synths using DSSI.
BEAST could fully support JACK and ALSA (including external midi i/o).

But that code needs to be written. IMHO a better investment than doing
architectural changes, which - although not too hard to do - will not
improve user experience.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan