From: Tim E. R. <ter...@ro...> - 2010-09-21 19:05:11
|
On September 21, 2010 09:57:29 am alex stone wrote: > On Tue, Sep 21, 2010 at 4:28 PM, Robert Jonsson <spa...@gm...> wrote: > > Hi Alex, > > > > 2010/9/21 alex stone <com...@gm...>: > >> Robert, a quick follow up. > >> > >> Christian over at linuxsampler has increased the programchangequeue > >> value from 100 to 512 by default. > >> One more challenge conquered. > >> He's also removed the max limit for number of ports in LS per device. > >> That means we could have any number of ports (i've got 116 so far) > >> through a single device in LS, being fed midi from muse (jackmidi). So > >> there's no longer a port limit in LS, and with the increased 128 port > >> limit in muse, makes for a much more capable large template/song > >> opportunity. If you need, you can increase the number of MusE ports to whatever you wish in globaldefs.h line 27: const int MIDI_PORTS = 128; // max Number of Midi Ports Barriers to increasing the number, were removed recently. I set it at 128 simply because I felt anything higher would be a bit of overkill in the ports list, making it a very long list. I didn't expect anyone would need anything higher, but, well, here you are! Did you get a chance to test the Jack-1 new midi buffer size option? Did it help? > > > > Great! > > > >> (And of course, now the limits are raised, users will push them further. > >> :) ) > > > > Hehe, I think I know who you are speaking of ;) > > > >> Alex. > >> > >> p.s. in the latest svn build, muse is crashing LS (zombified jack > >> message) with 450+ midi tracks, sometimes. If i start muse, then LS, i > > > > 450!!!!!! > > I can only guess at what kind of music you are trying to create. > > Constructing white noise from separate audio sources? ;) > > > >> get the message, but if i then restart LS (leaving muse running), then > >> reload the muse song template, it goes ok, with all ports (jackmidi) > >> reconnected, and no further zombie problems. (I suspect this is due to > >> loading a very large template, and something in muse doesn't like it, > >> i.e. a lack of a "pause" function, to let one part load, then the > >> next, then the next. I'm no coder, and this is pure speculation on my > >> part, but i've seen this in other apps, where large templates loading > >> "flood" the app, and it can't do it all at once.) 450 tracks, eh? My, you are a brave soul working with that many tracks. I can work with you to try to correct these problems. But first let Robert release version 1.1 and then we can breath and examine what's going on. Did you know that a long time ago MusE actually had a score editor? It was removed. I think that is a real shame, it would be the icing on the cake. Rosegarden definitely wins there. I actually looked at reintegrating the old score code, but I realized that it involves a lot of work because it is so inter-twined with the rest of the code. Or find a way to talk to the excellent QT4 MusE-Score by Werner. Someday... > > > > It's amazing that it does work sometimes (most of the time even!?) > > If there are problems you are probably right that it's because MusE is > > very busy and realtime performance of the computer suffers. > > Possibly it will work better if you have bigger audio buffers for > > jack. Though that is probably contra productive. > > > > Regards, > > Robert > > > >> It's too early to submit this as a potential problem, and i'll test > >> more in the next few days to see if it's definitely repeatable, but if > >> this initial comment prompts an obvious answer for you clever fellows, > >> then well and good. > >> > >> -- > >> www.openoctave.org > >> > >> mid...@op... > >> dev...@op... > >> > > Robert, i think i found at least part of the challenge. > > If i start muse with the intended file, it loads ok, and doesn't tell > LS to misbehave. (so to speak.) > > If i start with a file, like default, then attempt to open another > file, particularly a big one, then the errors come, and the zombies > come out to play (and once this happens, the intended file seems to be > prone to errors from then on). So it seems it's the "transition" from > one file to another in the same instance of muse that is prone to > problems. I've opened and closed a lot of big files today testing > this, and provided i don't attempt to keep muse open and go from one > file to another, instead starting fresh each time, then all is good, > even at a low audio buffer size. (Remembering i'm using jack 0.119.0 > from svn, in which i can set the midi buffer size independent of the > audio. At the moment i have audio at 256, and midi at 512.) Yes, there have been issues loading new songs without restarting MusE, I've been fixing them, even the very latest fixes deal with this. It's much better at handling this now. > > I'm ok with starting fresh each time, now i know what works and > doesn't, but this might be worth sticking on a long term to do list > somewhere in case others have the same challenge. > > I'll also defend muse here a little, because even with these sorts of > challenges (and the knowing how to avoid them, or at least being aware > of them), when it's running it seems fine, and i've been able to work > for long periods without interruptions, or crashes. (score one for > muse, in the competitive cauldron that is the linuxaudio community) I run it for many many hours editing, playing, practising very complex audio + midi songs and it's pretty darn stable, although there is the rare problem now and then. But my system is 32-bit. There seem to be issues with 64-bit systems. > > I'm writing orchestral and filmscore music here with large sample > libs, although indeed some might call it an historical version of > "white noise", or just "noise" :) I hope to have my website up fairly > soon, once i get the first batch of "noise" written and polished. (He > says, knowing the tens of thousands of midi edits still waiting around > the corner) Tip: Did you know you can edit multiple midi parts in one single piano roll editor by selecting the parts in the arranger and hitting Ctrl-E ? Looking forward to seeing some of the results. Thanks. Tim. > > Onwards and Upwards.... > > Regards, > Alex. |