From: Robert J. <spa...@gm...> - 2012-10-02 08:27:52
|
Hi Martin, Old mails, good times :) 2012/10/2 Martin Drautzburg <Mar...@we...> > Hello all, > > I've been away from muse for some time and just compiled the latest 2.0 > version. > > What happened to these cool ideas which came up in 2009? Are they now fully > implemented or were they discarded? > > Is that the "python support" which you can enable at compile time? > > I browsed the muse pianoroll menus trying to find a way to pipe a part > through > an external script, but couldn't find anything. > > Is there any documentation or tutorial about muse's scripting capabilities. > There are two scripting possibilities in MusE. 1. simple but quite powerful. In the pianoroll you have a Plugin dropdown. The plugins listed there are scripts operated through a pipe, see the share/scripts folder in the source tree for a brief specification and the source for the scripts. The scripts are more or less proof of concept though. I've been thinking several times to make some scripts for algorithmic note creation, has not happened yet though. On a related note, some of the scripts use PyQt4, this isn't handled gracefully, I don't think you get any good error if PyQt4 is not available. 2. Which is what is described below I think, this is unfinished work and as far as I know this does not compile. WillyFoobar on the devel list has expressed wishes to fix this, atleast the compilation problems. Regards, Robert > > On Saturday, 17. October 2009 19:48:53 Mathias Gyllengahm wrote: > > 2009/10/17 Martin Drautzburg <Mar...@we...> > > > > > On Saturday, 17. October 2009 14:03:56 you wrote: > > > > muse = Pyro.getRemoteObjectOrSomethingLikeThat('Default.muse') > > > > parts = muse.getTrackParts("Track 1") > > > > part = parts[0] > > > > events = part['events'] > > > > events[0]['length']=2 * (events[0]['length'] > > > > muse.modifyPart[part] > > > > > > > > Everything except the last line works right now. Yes, it requires > some > > > > manual coding but I think it's worth it. It makes it possible to make > > > > an interface that is selfexplaining instead of having to dig into > > > > MusE:s internals, which are a bit messy. > > > > > > I understand. Very cool. > > > > > > Do I understand this correctly, this: > > > > events[0]['length']=2 * (events[0]['length'] > > > > > > just operates on the python side and does not affect Muse's data > > > directly? It > > > is the last line which writes things back to Muse (and you meant to > say: > > > muse.modifyPart(part) - in round brackets). > > > > > > part['events'] still looks a bit unpythonic, you would rather expect > > > part.events instead, but that's really a minor thing. > > > > > > Just for curiousity: how did you solve the concurrency issue? I suppose > > > within > > > Muse everything is controlled by events (mouse, keyboard, timer, midi > > > ...). How and when is the python interpreter given control? Does it run > > > in it's own > > > thread? Will we eventually need semaphores, so the python activities do > > > not interfere with "native" Muse activities? > > > > > > Hi! Yes, wrote the example in the middle of the dinner rush. The > python > > > > side is simply given a copy of MusE:s data at the time of the function > > call. The last one should be muse.modifyPart(part), which is the one that > > modifies the part. > > > > The Python interpreter runs in a separate thread. It starts by launching > a > > Pyro naming service where it exposes a remote object called muse, which > is > > simply a wrapper for the calls in a Python module called 'muse'. The best > > thing would be to skip this wrapper class and implement the functions in > > the namespace as a class in itself instead of wrapping the global > > functions. But that can be changed in the future. Code executed in the > > Python interpreter context in the end all ends up in the audiothread > which > > processes one message/command at a time. The gui thread can do things at > > the same time, of course. This means things should be synchronized to the > > extent that the gui and python threads shouldn't mess things up enough to > > crash MusE - not working on the same data structures at the same time. > > However it's perfectly possible to make a mess by f.ex. working on the > > same parts of the song at the same time (e.g. you can delete a part via > > gui while running a python script that tries to modify that same part). > > However, with freedom comes responsibility. :-) > > > > BR, > > Mathias > > -- > Martin > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |