From: Guillaume L. <gla...@te...> - 2001-11-22 17:19:19
|
Just got this. ---------- Forwarded Message ---------- Subject: rosegarden Date: Thu, 22 Nov 2001 13:45:48 -0330 From: "Leemet, Juhan" <Juh...@xw...> To: "'guillaume laurent'" <gla...@te...> Cc: "'ju...@lo...'" <ju...@lo...> I've been interested in your Rosegarden work for a while. I used to be an amateur musician (hiding inside a computer software engineer) for years and I'm trying to get back into something more creative again. I've been wrestling with Mandrake Linux, trying to get alsa-0.9.0 sound drivers to work, since they seem to be required by the more interesting sound/music software. I think I've built an RPM package of sorts of the 2.1 version or Rosegaren, but I haven't checked it out or done anything interesting with it yet. My ideal goal would be to build a small, personal "studio", wherein I can "figure out" and/or write music, and record/play a mix of midi and audio. For personal skill development, I'd like to be able to record voice, guitar, bass as (single overlayed tracks of) audio. Then, I'd like to "fill out" the arrangements with midi, either input from notation editor (e.g. Rosegarden) or midi keyboard (my cheap Casio might work OK). I get the impression that such a software beast really does not exist yet. There are multitrack recorders like ardour (don't quite have it working yet, see my alsa-0.9.0 problems above) and there is Rosegarden (for notation and/or midi). I'm not sure where "noteedit" fits in whether it is like Rosegarden or a sub/superset? My impression is that there are real difficult problems (esp. viz. time?) in matching up midi scores and audio tracks? Some software can apparently do time stretching/compression without changing pitch (the mind boggles!), but I don't know how good they are, since I haven't heard them. General Midi on "toy keyboards" in theory should be good, but most sounds like garbage (to me), except for a few voices, which are sort of OK. Another problem I anticipate is how to (effectively) deal with percussion. Maybe a (single?) drum pad as input to Rosegarden notation? Just curious... Why are you naming/numbering the new sources/packages starting with 0.0.0 again? I would have thought that something like 4.0.0-experimental, or something like that would have been more appropriate? Then go through 4.n.n-alpha, 4.n.n-beta, maybe 4.n.n-pre, finally to 4.n.n for an official release? Are you going to work on 0.n.n for all your prerelease work, finally releasing 4.0.0? At first I was confused by 0.1.2 in relation to 2.1pl3, but maybe that was just me. Another option might be to call the program rosegarden4, and then go through 0.n.n versions. Then I don't know whether it should change back to rosegarden-4.0.0 for release, though. I guess there is (still?) no ideal way to do it. p.s. I was kind of disappointed that you folks had started with CORBA and given up on it. I guess there is a lot of overhead with CORBA, but I was hoping for an approach that could integrate a network of computers, each doing a part (recording, playback, midi) in the process. That could (?) give the flexibility (computers and sound boards are pretty cheap these days) of adding compute power on demand, without changing architecture. KDE is supposed to have some DCOM ability, but I don't know much about it. I guess if one is doing multitrack stuff on multiple computers, one should consider some kind of synchronization time codes? I've seen some reference to the idea of designing/defining a new LAN protocol, like a high speed MIDI, but don't know much about it. I would have thought that MIDI (on a relatively slow serial link) was too slow, but I guess it works well enough? Does it start to "bog down" as the arrangements and (numbers of) devices get more complex? ------------------------------------------------------- -- Guillaume http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2001-12-07 23:54:43
|
It seems we have a slight naming problem. This is the second mail I get from someone who asks something about rosegarden without specifying which version (the other one was in french so I didn't forward it). ---------- Forwarded Message ---------- Subject: rosegarden Date: Fri, 7 Dec 2001 14:27:57 -0800 From: Eric Reesor <jo...@te...> To: gla...@te... Hello, this is not a virus, although ideas sometimes are like one. Can't find the library list necessary to install Rosegarden on my linux box any suggestions? Running RH 7.2 is a command line none X approach more effective? after untarring which directory do I switch to? or do I need to make a new directory first? A command sequence hint would help. Anyway thats not the reason I'm writing this note. Is there anybody writing a music server for linux? This idea could easily be used as a web based chat interface for musicians. Having a midi interface would not be essential, but good transfer of MXML or music java though an Icq style interface would attract composers and litterate musicians. The server side could handle the midi for the illiterate if necessary. The scripting interface could be kept to a plug in that could return notation and or midi from the server. Thanks for your time. Eric Reesor ------------------------------------------------------- -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2001-11-22 22:24:34
|
On Thursday 22 November 2001 20:16, you wrote: > drums). I hope RoseGarden is planning on incorporating analog with MIDI > like CakeWalk because that is why I downloaded it Yes, that's planned although as I was saying to Juhan, we're quite far from that yet. > impressed by Rosegarden 2.1 which is what I'm currently using). But I > don't have much experience coding so I'll start with simple things at > first, okay? I printed how the source to RoseGarden so I can get an > overview of it (I seem to understand stuff better on paper). > > These are some of the things I would be interested in doing: > > 1. I don't really like lots of floaty windows. I would like to > make the playback interface dockable(and floatable if you like). Yes, but not yet :-). Qt3 offers much better facilities for this, so any code you'd write now would be thrown away when we move to KDE3 in a few months. Therefore I suggest you don't worry about this for the time being. > Is it pretty complete? I think it is. Bownie could tell you more about this, but unfortunately he's away on vacation at the moment. > It just crashes on my machine. I may > have to spend most of my time just getting it to work. Check docs/howtos/artsd-mcop-notes. It should be in the distrib, otherwise it's on CVS. You can get it trough this URL : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rosegarden/docs/howtos/ > 2. Adding an interface for properties like volume, patch, name, pan. Now *that* is something which is planned and not too hard to do, so you're very much welcome to try. > 3. I already like the staff view pretty well(I guess that's where > most of the work has been done so far). Indeed. I plan to start working on the piano roll in the near future. > 4. More robust song writing capabilities. That is ? > What do you guys recommend as a starting point? Something that > needs to be done but wouldn't require already knowing most of the > existing codebase. Your item #2 is a very good candidate. > When I do start writing stuff, how do I upload the changes? Posting patches (output of cvs diff -u -b -p) on this mailing-list (rosegarden-devel) is the most appropriate way right now. -- Guillaume. http://www.telegraph-road.org |
From: Henry S. <henryst@MIT.EDU> - 2001-11-23 12:43:39
|
While I was trying to get my Arts/MIDI to work I ran into another program called Brahms for KDE. It already seems pretty complete(judging from the screenshots). Do any of you guys have any experience with it? (i.e. Why was the rosegarden4 project started when there was an app already much ahead?) I'm just wondering. I guess it's fine having different programs around, but considering how similar the objectives seem to be, I wonder about duplicated efforts. I guess what I'm saying is: I was planning on coding for rosegarden, but this Brahms looks pretty interesting... I need some convincing to stick to rosegarden. Regards, Henry Stanaland |
From: Chris C. <ca...@al...> - 2001-11-25 14:46:07
|
Henry Stanaland wrote: > While I was trying to get my Arts/MIDI to work I ran > into another program called Brahms for KDE. It already > seems pretty complete(judging from the screenshots). Do > any of you guys have any experience with it? Obviously we're aware of it, to varying degrees of familiarity. You're quite right: it's a far more complete sequencer than Rosegarden is at the moment, and it's been in development for much longer than Rosegarden-4. I wouldn't wish to dissuade you from contributing to Brahms, because it's a very worthwhile project. A few differences between Brahms and Rosegarden-4 -- some in our favour, some in theirs: -- We do notation better, and it's probably more of a priority for us (it certainly is for me). Actually we have two quite opposite priorities: I'm driving for good notation, and Bownie is driving for a sequencer that he can use for his own home-studio use -- he currently uses Logic, and never uses notation at all. (Guillaume is driving for something that actually works.) Trying to reconcile these opposites was what took us such a long time in discussion & design before we managed to make anything work at all, but now we think we have a pretty good base for it and we think that gives us a lot of potential. -- Brahms is (as I understand it) intended to have a basic core that can be operated from the command-line as well as the GUI, and that is in theory nicely scriptable and extendable. We'd like to make as much as possible scriptable too, but we don't have it as such a fundamental priority. Still, you can already instruct Rosegarden-4 to do various things from DCOP messages from the command-line. -- We think our code is better than theirs. It's an arguable point, of course: does our heavy use of templates (e.g. in our Event class) simplify things, or is it a clever-clever piece of stylistic pointlessness? And we definitely have some nasty stuff, like bits of the organisation in gui/. And their code has improved quite a lot in the last year, I think. But on the whole I stand by this one. -- I also like to think we care more about the details: we want the GUI to look good and work "right" rather than just working at all, and we'll try to get the basics right before we go too mad with all the features. And personally, I'd like to end up with an application that you can just run and that won't crash too much. I can still never remember the magic incantation that gets Brahms started on my machine without a segmentation fault, and this is supposed to be a 1.0 release. To be honest, the main reason for the existence of Rosegarden-4 is just that we've been trying to get started on a rewrite of Rosegarden 2.1 since long before Brahms existed, even if it's only fairly recently that we've really got stuck into it. But that's okay; we're making excellent progress now, and we think we'll end up with a different enough application to make it worth the effort. And besides, we enjoy it. Chris |
From: Guillaume L. <gla...@te...> - 2001-11-27 23:42:01
|
On Friday 23 November 2001 13:36, Henry Stanaland wrote: > While I was trying to get my Arts/MIDI to work I ran > into another program called Brahms for KDE. It already > seems pretty complete(judging from the screenshots). Do > any of you guys have any experience with it? Yes, we keep an eye on it. > (i.e. Why was the rosegarden4 project started when there > was an app already much ahead?) As Chris said, it's mostly because, well, actually it wasn't. Rosegarden per se predates even KDE by several years, the rewrite, as a planned project (not as code), predates Brahms by at least a year I think. > I'm just wondering. > I guess it's fine having different programs around, but > considering how similar the objectives seem to be, I > wonder about duplicated efforts. At some point when the development of Rosegarden didn't seem too certain I seriously looked into collaborating. However, the first thing I instantly would have wanted to put my hands on (namely the core classes, because the code was, well... you just look at it) the author would rather work on alone. So that pretty much killed the idea : we simply wouldn't have felt comfortable working on this code base. > I guess what I'm saying is: I was planning on coding > for rosegarden, but this Brahms looks pretty interesting... > I need some convincing to stick to rosegarden. It's not our job to "convince" you, we're not into advertisement or marketing. You're a grown-up, at least enough to make your own choices. We'll be happy to work with you if you want to, but we won't resent you if you prefer working on Brahms. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2001-11-25 14:56:33
|
Guillaume Laurent wrote: > I plan to start working on the piano roll in the near future. Yeah, I was thinking about this the other day. I started with the assumption that we could get a fairly serviceable piano-roll by simply dropping a different implementation of notationstaff.cpp (and notationhlayout.cpp, although that should be mercifully simple compared to the one for notation) into the existing code. And then I was trying to work out which bits of notation* really are specific to notation (or should be, if they didn't have a few kludgey references to notationelements in them). I reckon this would be one way (of several) to slice it: -- notationcanvasview should only know about QCanvasItems, not NotationElements. That means it would have to become unable to select specific elements by pitch, but that's okay, it could just pass the coordinates in to the notationview's mouse-press callback. -- in fact, notationview could actually lose its knowledge about notationelements too -- it has very little left. -- notationstaff should probably become (yet another) base class, which owns its own staff ruler, and from which the notation and piano-roll versions are subclassed (each with its own code for generating the canvas items). Alternatively we could move the code that generates canvas items into specific notationelement implementations, which might be good if we did decide to put notation-specific methods into notationelt in preference to using properties (e.g. isBeamed()). I still think the latter is probably not necessary though. -- notation tools would have to continue much as they are. With a bit more cleaning up in this way, I really do think we could end up being able to instantiate basically the same class (our current NotationView) for score and piano-roll, and for various other future sorts of editor; we just specify a different staff class, layout classes and a different set of tools. (Most of the notation tools would probably be nice to have available in the piano-roll too, I think, but obviously they can't be the whole story.) I'd welcome more discussion about this; I think we can do the necessary work pretty damn quick once we've decided what it is. Chris |
From: Guillaume L. <gla...@te...> - 2001-11-27 23:49:55
|
On Sunday 25 November 2001 15:56, Chris Cannam wrote: > Guillaume Laurent wrote: > > I plan to start working on the piano roll in the near future. > > Yeah, I was thinking about this the other day. I started with > the assumption that we could get a fairly serviceable piano-roll > by simply dropping a different implementation of notationstaff.cpp > (and notationhlayout.cpp, although that should be mercifully > simple compared to the one for notation) into the existing code. > [...] I need to think more about this one, and I'm just too tired to that right now. My immediate concern is interactivity, a piano roll offers a completely different edition scheme than a notation view (for instance you can move the notes horizontally, thus changing their starting and ending point). I'll see tomorrow. -- Guillaume. http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2001-11-28 17:40:57
|
Guillaume Laurent wrote: > My immediate concern is interactivity, a piano roll offers a completely > different edition scheme than a notation view (for instance you can move the > notes horizontally, thus changing their starting and ending point). Hm. At first that sounds like it's only a different tool; we just have to offer a bunch of piano-roll tools as well as the notation tools. But I guess as soon as we want to provide tools that (for instance) resize notes by dragging their left- or right-hand edges, then we also need some capabilities from the notationcanvasview that it doesn't currently have. Chris |