On May 6, 2014 01:37:21 PM Robert Jonsson wrote: > Hi Tim, > > 2014-05-06 2:18 GMT+02:00 Tim E. Real <[email protected]>: > > On May 5, 2014 10:18:03 AM Robert Jonsson wrote: > >> Hi Tim! > >> > >> 2014-05-04 18:39 GMT+02:00 Tim E. Real <[email protected]>: > >> > Hello Robert, and Florian, I'm still here. > >> > > >> > Robert, I've spent the last several MONTHS fixing the master here. > >> > The master as it stands now is just not ready for prime-time > >> > > >> > and it would NOT be good release. > >> > >> Why is that, I think it works quite nicely, or are you aware of glaring > >> bugs? > > > > Yes. Some incomplete major changes were made which left some bugs. > > Current master is not the master that you knew several months ago > > > > before the changes. It is not functioning as it was before. > > > >> I mean, the stuff you are building will probably add lots of neat > >> enhancements but HEAD is working nicely for me, except for the two > >> mentioned problems. > > > > They are necessary to correct the bugs. > > It's really only two things I'm doing: Undo and operations - no fancy > > > > features here, just fixes 'under the hood'. > > > >> If you know of problems with HEAD my argument is void but otherwise I > >> think we can release a maintenance release soon and then in a month or > >> two we can release your stuff. > >> That would be more alinged with our intentions to release more often. > >> Which seldom happens ;) > > > > That's why I've been saying it's not a good time to release until we fix > > > > these problems. Releasing right now it'd be a step backwards. > > > > Better off released with my unfinished working fixes committed NOW, > > > > rather than in its current state. > > > > Release if you want, but if you can give me a week or so, I will try my > > > > darndest to have something ready beforehand. > > No, if that's the case I definitely agree we should wait. > It works for me but probably I don't touch enough of the features. > Maintenance releases aren't so good if they break things. > I'll wait :)
OK you got it, we're on! I will do my best. > >> > But my fixes are not quite ready for commit yet. > >> > There was a lot of stuff that needed (needs) fixing. > >> > I estimate maybe a week before I have something, I really am working > >> > > >> > very hard to get something ready because I knew that soon others > >> > may have commits of their own, as is the case here, possibly > >> > wanting to overlap some of the fixes I am doing. > >> > > >> > The first problem you mention above is likely due to these bugs > >> > > >> > and may be fixed by my fixes. > >> > > >> > The second problem you mention, well, I guess that's up for debate. > >> > I'd prefer to keep the Jack midi thing... > >> > >> I have no problems with having jack-midi as default if they were > >> functionaly equal but I have had quite a few problems with the > >> jack-midi solution lately. Best would be to fix it but until that can > >> be done I think we should fall back on a working solution. > >> I'll try to elaborate on the problems I have had in a bug soon. > > > > OK, tell me. That's my department so maybe I can help. > > I've no trouble with the jack-midi here. > > I think jack has had some changes lately, possibly regarding device > > naming? > > I'll try to elaborate, don't think it has to do with jack versions. > > Well, first off there's a pedagogic issue, but we have been over that > before. Jack-midi isn't enabled by default in jack which does stump a lot > of users. I have helped quite a lot of people getting it running. Most of > them have gone with -A when presented with the choice. > I was planning to do some new tutorial videos shortly that would > explain this a bit better but until jack enables jack-midi by default > it doesn't speak in it's favour. > (i see now, reading up on it, that latest jack1 has improved the > implementation, seems it's still not default though) > > The problems I personally have come across are less clear cut. > (This is of the top of my head, not entirely sure what the problem is.) > > I think the biggest problem happens if I start with a working song > where I recorded stuff through an external keyboard. > If I then start jack without -X seq (or -X alsa_midi which seems to be > the new) and open the song, the external midi device is gone (of > course). > If I then store the song in this state, close everything down, Ah there we go: When you do that the song loses the jack devices. So once you restart with -X you have to go back into the midi preferences and re-create/re-assign jack midi devices to all your midi ports. Definitely you have to be consistent how you start jack EACH time you start MusE, and open then STORE a song. It's a fair and reasonable requirement, I think. Too bad, I don't know of any easy way around that unless we somehow keep a record of previous midi configurations and somehow offer the user to re-establish them. Tricky... Keeping a list of previous configurations... Hmm... Flo said he wanted to add some more device abstractions by just storing names, or something like that. Unfortunately not even that would help here when you fail to use -X, since the actual devices won't even exist then. And there's a gray area here since it is said one should use one of the alsa-jack midi bridges instead of -X. And now one of those good bridges (I think Fons') is in jack-1 (I think, not -2). I wish there was a way for MusE to know if jack had been started with a midi backend, so MusE could automatically know whether to use ALSA or jack midi. > reenable -X alsa_midi and open the project the input device either > won't appear or won't work, possibly I have had both happen. And > there's no way I have found to get it working without messing with the > internals. Or as I say above, manually re-creating/re-assigning jack midi devices in the midi preferences dialog. > > I'll try to narrow this down further when I next have time. It's not > out of the question I have made it worse myself, I know I have some > changes in my source tree that might interfere ;) Well I haven't touched anything jack related (I think - I'll check), so there shouldn't be any overlaps if you want to commit some work there. > >> > I hate to discuss what I'm doing for fear of jinxing my work, it has > >> > > >> > a habit of doing that, sometimes I discover a stumbling block that > >> > shoots down everything I have tried and it's back to the drawing > >> > board. > >> > > >> > So briefly, I have fixed things that Flo and I discussed (every event > >> > gets > >> > > >> > a unique ID, problems with selections etc), and I have implemented > >> > what > >> > we discussed about operations: Operations are now 'collected' > >> > beforehand > >> > in the non-realtime stage and executed VERY FAST in the realtime > >> > stage > >> > with very simple instructions. It doesn't get much faster than that. > >> > > >> > Previously the realtime stage was doing all the 'collecting' and > >> > wasting > >> > > >> > a lot of time, doing a lot of searching and even mem allocation - a > >> > no-no. > >> > > >> > There are, and have been, a lot of challenges and snags along the way. > >> > For example I've found the tempo, signature, and key lists have a > >> > design > >> > flaw> > >> > > >> > that prevents them from working with undo, at tick = 0. > >> > > >> > So I'm fixing that right now. > >> > > >> > It's been very intense and complex fixing these bugs. > >> > Yes, it has taken THIS long, but I hope to have something soon, because > >> > it > >> > > >> > is finally coming together and showing signs that it WILL work. > >> > >> Sounds cool! Does this have any impact on the song file format? > > > > None so far. > > > > Winter just won't go quietly. Spring has been very slow to arrive here. > > Finally getting better but still cold, rainy, windy... Come on Sun! > > This week looks a bit better. > > Hehe, same way here. March and april was actually quite nice here but > it's taken a dip for the worse. No real warmth yet, come one sun! Makes me wonder what kind of summer we're in for. I'll think about the jack midi thing more, if I can think of anything else. Thanks Robert, nice to hear from you, see some activity again. Tim. > > Regards, > Robert > ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
