-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) iQEcBAEBAgAGBQJSQMhFAAoJEHPd9QK/nPqlmwAH/ik1RLLS+mm81rYHJ2hHoYey cw353jBWBHFGSuhFJDxXl421ZuClpgSMxi2Ufb+mFr8t7xTQGwRMscFfL25ve4Fj EvKAz87gcDrTOTgNiaUWmoz1jDLzDG5e/JFGiww06VsDG/qwgW3UcChLx/n3+Rqj i3YGY8Qattt6q4yTT2JCj0+I/UjMvvOzd+jg5unOAGxh7YiRxi8k64qcDYZQ7gvC dhJ9ig5tyRm5L/7FZ6PmVQmWdKz/kK/quOZkjTadT31T8C7HUpsupe01JNIRJdyn KWghd/2qf4tYWzDsxUt4gBbIdQAMrPJqdLYNu12mVuWeXgu3LQBkFvF8rCgKjno= =IXJu -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
