[LAD] [Lmuse-developer] Just an information about the state of affairs - Re: forking (was Re: Aeolus)

[Florian Jung]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I should have awaited the ML registration confirmation; here's the
message I just sent and which got rejected because of my
not-yet-complete registration:




Dear Fons,

Am 23.09.2013 18:51, schrieb Fons Adriaensen:
> On Sun, Sep 22, 2013 at 02:18:58AM -0400, Tim E. Real wrote:
> 
> Please explain why musescore refers to a webpage that was closed 
> six years ago (when I moved to Italy), while the code that is on 
> github is of more recent date and can't have come from that site. 
> Do you want to create the impression that Aeolus is no longer 
> maintained?

Please note that we (this includes Tim E. Real) are the MusE-Sequencer
(or shorter: "MusE") development team, and not affiliated with musescore
in any way (not any more.).

Although this issue probably dates before the time I joined MusE, I
guess that our Wiki refers to a page that was closed six years ago,
because the Wiki is actually older than six years. Indeed the log
tells me that the page was last edited in 2006.

Of course, Tim can speak for himself, but I am sure that there
never was any intention of making Aeolus look abandoned. It's rather our
wiki, or at least certain pages which are unfortunately hardly maintained.

Please tell us what you'd like us to do to the Wiki page. Delete it? Or
just update the information on it?

I would have been happier, though, if you just had sent us a short
notice in the first place...



> 
>> Anyway, question: How hard would it be to make Aeolus available 
>> as a plugin like DSSI, LV2 or LinuxVST, or... WinVST?
> 
> That is not going to happen. There is no reason why Aeolus should 
> be a plugin, functionally it is perfectly usable on its own and it
>  doesn't need anything hosting it. You could as well ask for
> Ardour3 as a plugin.
> 
> If you want to use Aeolus to render your scores, all you need to do
> is send the midi data. I assume that musescore can send midi to 
> external (hardware) synths ? Then it can do the same with Aeolus.

again: we are not Musescore. That is a very different project for many
years now.

> 
>> Plugins are preferred over external apps - no added latency.
> 
> That is a bogus argument. Aeolus actually *adds* latency 
> (configurable per stop, to emulate distance). And a score player 
> can easily compensate for any unwanted latency, just send the midi
>  data a configurable time ahead.
> 
>> When no plugin is available, one resorts to quickly hacking up an
>> embedded version of some cool app. It tends to grow from there.
> 
> Moving a bunch of non-trivial apps into a single process is 
> technically a very dubious approach. Nor is it necessary. It's 
> trivially easy to launch on app from another, make the necessary 
> connections, and send the commands to setup the external app as
> you want. If anything is missing to make that work, it could be
> added.
> 
> In the case of Aeolus, the GUI is a plugin chosen at run time, and
>  it talks to the DSP code only via asynchronous messages. The only
>  thing you would need to do is write an alternative plugin that 
> sends the same message over e.g. a socket, and you can control the
>  entire thing, including saving and recalling state, from within 
> your app.

It's a pity that this is how you see it, but I won't question your
opinion; just let me ask, will it be possible to create some sort of
DSSI-frontend to Aeolus? Some plugin, that can be loaded via DSSI into
every compliant host, and then actually spawns a new Aeolus process,
makes connections, displays the Aeolus GUI, but offers the benefits of
DSSI plugins like easy state saving and no need for session management?

> 
>> Let us host Aeolus some day. Be our guest!
> 
> What I've seen so far is rather Borg style assimilation (*)

could you please give me some examples, I don't quite understand what
you mean.

> rather than 'being a guest'. I decline that sort of hospitality.
> 
> The GPL allows you to use the code of the current release. If you 
> cripple it in the way you apparently want to, then you shouldn't 
> call the result 'Aeolus', or even pretend it is an organ emulator.

That sounds pretty hostile :(
Still (regardless of whether anyone here actually plans to do this!) I
don't understand your aversion against making it a DSSI plugin; why
should one not even call such a thing an organ emulator? It would be,
well, an organ emulator plugin.

I see some advantages in turning standalone softsynthes into DSSI
plugins, such all being maintained by the plugin host application,
easier setup and the like. I'd be glad if you could work out on you
arguments *against* making Aeolus a softsynth, for better understanding.


- -- Florian




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJSQMtoAAoJEHPd9QK/nPqlQ0IIAKUUyzWFuEe0QlOWcOLt5uGQ
duoSCYmUMleGvBcO6lgOMB3MX5eYa3Tnx8/9AIK8ND+DSVaYVThO+p8PuJLgzH0Z
sZEgR+rEURSWuIBQhLfRMlriwv/Cx267ahzAJvEps/Ny+XbhQNWabsoHD3G5HlHp
xhdbEo02T31fPCe6I/qE6vdgMSNzW6cjZSIsJxQB5michdCzRYRZB4VFaWp9xgNW
rjDKYPaXEEDiGdzDZeUmhbNgjUo4nFsaLnTH9fF+AipHzwyBMahCQDubNMYUcOLE
gU9M4+p5hUYE3nYNk31skIlR5HjBx7076jT899XiYtXyZBy0fQT5SN3NNDG7xM4=
=30a/
-----END PGP SIGNATURE-----