I like slicehost for a number of reasons, but you have to be willing to use a command line because there is no GUI unless you install one (because you're getting a virtual server with full root access).
I currently use them, for the Rosegarden website among others (wonder whether I'll regret that link -- that's running on their most basic VPS package). The connectivity appears good and I like the command-line-only approach.
What's not so good is that they only offer 64-bit distros with relatively little RAM for the price, so you can run out very easily (or pay a lot).
Really though, whatever you do your best approach to ensure you can bring up the site anywhere at short notice without losing a significant amount of data. Run your own backups, manage the DNS elsewhere, and so on. If you can afford it, maintain another ready copy of the site at a different provider.
Anyway, about feature requests: just make it your goal to have RG assume ALL of the features of the various other sequencer programs out there Get real, these products have resources we'll simply never match.
The fact is, that would be a very poor goal. It's something we actively don't want to do, unless someone else is providing the resources to do it.
We have to balance the needs of quite a lot of different sorts of users. Matching all of the MIDI functionality found in Cubase may make an ideal program for some users, but if we spent all our time doing that, we'd be so behind on other features as to have a program that was useless for most of the people who want to use it now, including all of the developers who caused the project to happen in the first place.
This thread has so far followed the pattern of having one poster or another pronounce that Rosegarden "must" support feature X before it can even be considered 1.0, followed by Guillaume replying half-apologetically to say that we'd love to do that if we could find the time. The plain fact is that we've taken the decision that most of these things are not essential 1.0 features. And there's no reason we should apologise for that. You can disagree with particular instances -- clearly you do, and we'd encourage you to make feature requests with use cases so that we, and other developers, can take them into account when prioritising work in the future. But it's absurd to imply that a program isn't a worthwhile program at all because it doesn't do a particular feature that you personally want. That way lies madness, and/or Mozilla. Far better to accept that there is room for more than one program out there.
The source distributions don't have to be made available to everyone, only the users of the software.
Depends how you distribute your software. Section 3(b) of the GPL (which only applies if the source is not included with the original object distribution) does indeed require source to be available to anyone, and for no more than a nominal fee.
In any case, so long as I can get your source code free, legally, from anyone you distributed it to, then for consumer applications at least your software is effectively free. As, in practice, GPL software is.
This doesn't mean I particularly agree that the GPL causes the situation in which it's hard to charge directly for software applications. Other comments here have pointed out (a) that it was always hard to make money selling software directly to consumers and (b) that few consumers pay anything much for proprietary software either, any more. The model in which you distribute free software and sell the services around it is only a formalisation of the way that most proprietary business software generates most of its revenue anyway.
I really wish the author of the article has addressed this particular myth as well. Reading the article, I could already see legions of Slashdot comments dismissing the whole argument on the grounds that "Free Software refers to freedom".
The plain fact is that Free Software does indeed appear in practice to be always free in terms of price. (Or effectively so, in the case of e.g. Linux distributions with several thousand packages for USD50 or less -- rates at which there's no way an individual author can get any financial benefit.) The GPL even ensures that software will be close to free of price by mandating that anyone can get the source code and build it themselves for no more than a nominal distribution fee.
Indeed, look at your own example -- a business selling a database product may choose to release it as free software, and offer a gratis download. So their software is free of price. Your example doesn't even illustrate the point you're trying to make: why is that? Because there are no examples that do?
Regardless of the moral intention of the GPL (and I largely approve of it and use it for my own work), it's stupid to dismiss the fact that GPL software is almost always free of price simply by saying that in theory it need not be so. Unless you can show some application of your theory in the form of a workable way of charging profitably for the actual software (rather than services around the software), then your argument is perhaps interesting, perhaps relevant somewhere else -- but not relevant here.
> Out of curiosity why are MOTU cards not supported?
Oh, the usual reasons. MOTU don't want their cards to work with Linux, probably because they have a big investment in dedicated software to go with their hardware on other platforms. They won't release specifications, and they've been actively hostile towards any approach from developers offering to support them for free.
Well, they're both audio and MIDI sequencers for Linux. They both support outboard MIDI gear, native Linux ALSA soft synths, and audio and transport synchronisation through JACK. Both look and feel somewhat like the big sequencers for other platforms. Both use Qt for their GUIs, though Rosegarden also uses the KDE libraries. I happen to think Rosegarden has the more polished GUI, but I'm biased (see disclaimer at bottom).
Both support arbitrary numbers of MIDI and audio tracks, with audio mixing and routing capabilities. Both support LADSPA effects plugins, of which there are hundreds available free. Both can (with some work!) be made to use VST effects through vstserver. MusE can host VST instruments with libfst using Wine; either of them can drive VST instruments hosted separately using jack_fst. None of these VST solutions is currently at all easy to configure and build, but see here for more information. Rosegarden is implementing the DSSI synth API and will probably ultimately use a DSSI wrapper for VST instruments. Rosegarden can also be run without audio support if you only want MIDI or score, whereas MusE always requires JACK.
My rather fuzzy impression of the difference in "feel" between them is that MusE feels like it came more from a studio/MIDI gearhead background, Rosegarden more from a composition background. MusE is a bit further ahead with things like instrument plugins, audio routing (send/returns etc) and automation. Rosegarden places a lot more emphasis on the score editor, whereas the one that used to be in MusE was actually removed completely for the 0.7 release.
Rosegarden is a somewhat bigger and more complicated program than MusE (c 200K lines of code vs 130K LOC), which you may see as good or bad depending on whether the extra code happens to do stuff you want or not. They're both written in C++, should you happen to care.
On the subject of soundcard support: the usual quick answer is "it's probably supported unless it's FireWire or made by MOTU". In particular the current M-Audio, Terratec and RME semi-pro gear mostly works fine, as well as most consumer cards. The lack of FireWire audio device support currently is a pain though. Anyway, see the ALSA soundcard matrix for detailed information.
(Disclaimer: I am a Rosegarden developer and, although I track MusE CVS, I have never actually managed to get MusE 0.7 to build because I don't have the right libraries and autotools. So do take all this with a pinch of salt.)
9wm is a nice window manager, the first one I ever saw that was both complete enough to use and simply and clearly enough coded to understand -- the earlier twm and uwm have really nasty code in comparison. I was shocked to read elsewhere in this thread that 9wm's author (David Hogan) had died recently.
9wm was the basis for both lwm and my own wm2, which were two other early self-consciously minimal window managers (wm2 was first released in 1996).
Are the PDF examples on the latter using the standard Finale font? Now that is nasty. There's certainly right and wrong there. Too round, and the stems don't look properly attached. No balance. If the others are Garamond and Plantin, that's Arial.
For example, most fonts get the half-notehead wrong; that should be diamond shaped, not elliptical.
I take it you're saying that the line that forms the inside of the notehead should consist of two parallel (almost) straight strokes connected by curves, rather than a single ellipse?
In that case you probably did RC, for the Amadeus font certainly uses an ellipse. I'm not persuaded that there's any right or wrong there, though -- it's surely a question of taste. Yours is more like an old Garamond, theirs more like Plantin. I think theirs looks friendlier, feta looks more formal. I've seen far worse than both in printed scores, anyway.
Don't know about the smartmusic files (send me one, and I'll have a look)
They don't like to serve them to you if they can't detect their plugin. I'll have to take a closer look at the page source.
I think you might not RC, given the example (an opera score) I have in front of me at the moment, which looks fantastic.
Not that this is of much practical use to the average poverty-stricken Linux user.
I just went to Coda's website to see if I could see some examples of Finale output in PDF or whatever, and all I could find was a bunch of things that call for "the SmartMusic Viewer plug-in", which obviously I can't use. I guess it's the same idea as Sibelius's Scorch plugin, which I can't use either. Scorch uses the same file format as Sibelius proper, I believe; any idea whether these Finale SmartMusic files are the same format as the ETF files that Lilypond can import?
Re:"LilyPond might get there someday"
on
Turn-Key Linux Audio
·
· Score: 2, Interesting
Well, at least it's pleasantly quiet around here now.
I do actually know one professional music typesetting company that uses Linux almost exclusively. They use a very old, rather expensive text-driven program called Amadeus. In many ways it sounds a bit like Lilypond to me, with I suspect rather more flexibility from years of being messed around with for a huge variety of score-like situations (books, exam texts, freeform jazz scores with wiggly lines everywhere etc). I see it's listed in the Other Packages section of the Lilypond website -- have you ever seen it?
I'm arriving very late here so probably nobody will read this, but... As one of the Rosegarden developers I can confirm that Rosegarden will never be quite comparable with Sibelius or Finale, because it's intended to be a compositional tool (that includes the best score capabilities we can manage) rather than a score-typesetting program.
But I can't agree that Linux has nothing to offer the professional typesetter. Sure, Linux doesn't have so much to offer the typesetter who wants to use a point-and-click interface, but for a professional who only typesets score (rather than composing it), a text-based interface like Lilypond's is arguably more productive anyway. It's ridiculous to describe Finale as somehow a "more professional" typesetting application than Lilypond; how "professional" this kind of application is depends entirely on the quality of the end results, and Finale is nothing very special there. Finale may be more useful to you, but more "professional"?
fdsa:
define a piece of music by defining what note to play at what time with what instrument, but also what sample to play where, and where what lyrics go.
jcn: So you didn't even have a look? This is actually what LilyPond does
No, surely fdsa is right -- Lilypond doesn't really begin to address anything performance-related, and "performance-related" covers a vast amount of instrument, audio and interpretational stuff that a quick reference to samples doesn't begin to cover.
Lilypond can describe most of the data that a classical composer or a non-electronic performer would be interested in, but it's not a performance tool, which seems to be what "defining what note to play at what time with what instrument" is asking for. Lilypond and Csound squished together would be more like it, but only if you were happy to be working entirely in Csound synthesis.
does an appropriate language for defining a piece of music exist, a LaTeX for musicians?
Yes. There are lots of pieces of
music software that are more or less comparable to LaTeX, in that they do specific tasks from the command-line and textual input: Csound for synthesis, SoX for audio manipulation, Lilypond for notation typesetting. They're all excellent pieces of software.
But I guess there aren't as many people who need to do only synthesis, audio manipulation, or notation typesetting as there are people wanting software that only typesets text. Music is always going to have more of a real-time, interactive nature.
So far there are only pure MIDI sequencers or 100% recording applications
Several of the "pure MIDI sequencers" actually have some level of audio support: MusE, Jazz++, Rosegarden-4 and Brahms at least do. It's all pretty damn basic at the moment, but there are a few interesting initiatives like JACK (an audio connection toolkit, used by things like Ardour -- we've just got the basics of support for it into Rosegarden) that might help to perk things up in the near future. I think once a few applications get able to talk to one another, we'll have far more interesting prospects.
Caveat: I don't actually understand any of this stuff, I'm a notation guy.
All of the GUI audio apps I've seen for linux are crap compared to
professional windows apps. It's about time to do something about it,
but is the community of linux-using music-making dsp-coding geeks too
small ?
I think the community of linux-using music-making dsp-coding geeks
with enough time and good taste to work on quality GUI applications
probably is pretty small. Making GUIs is difficult and mostly not
much fun; it doesn't fit well with the scratch-your-own-itch style of
development, and you have to think about those users all the time.
Infrastructure is hard too, but often not quite so damn tedious.
I work on the Rosegarden-4
project, which maybe one day will be "somewhat like" Logic. So far
we have yet another half-decent sequencer with MIDI and a bit
of audio plus reasonable notation support, and we could definitely use
some help. But the potential is there, we're making good progress,
and I'm quite excited about the infrastructure, which I really think
is becoming good enough and consistent enough to support it.
Projects like DeMuDi surely are mostly a good thing. The software
is slowly getting there, and a push towards making it easier to find
and install all the bits and bobs you need can surely only help.
(Except of course that this is exactly what the mainstream
distributions should be doing anyway.)
I feel I'd better correct myself: there were some 50 posts on the RoseGarden list this year.
Indeed. But you were just as right before, really. Rosegarden 2.x is pretty much obsolete: there are still a few things it does better than its rivals, but not many, and the GUI, well, it was very pretty six years ago...
The very ambitious Rosegarden-3 development progressed fastest when I was in a really dull job a year or more ago, but it's been painfully slow going since. The main problem is just building up enough of a base to make it worth anyone else's while trying to do anything with it. Still, I'm persevering; the eventual aim is a bit different from that of Denemo or Brahms (though GSeq is probably closer) so it seems worth sticking with it for the moment.
Anyway, see Rosegarden's homepage for some development notes and the mailing-list archive; and the 3.0 code and docs, such as they are, are on GNOME's CVS server.
Slashdot Mirror
I like slicehost for a number of reasons, but you have to be willing to use a command line because there is no GUI unless you install one (because you're getting a virtual server with full root access).
I currently use them, for the Rosegarden website among others (wonder whether I'll regret that link -- that's running on their most basic VPS package). The connectivity appears good and I like the command-line-only approach.
What's not so good is that they only offer 64-bit distros with relatively little RAM for the price, so you can run out very easily (or pay a lot).
Really though, whatever you do your best approach to ensure you can bring up the site anywhere at short notice without losing a significant amount of data. Run your own backups, manage the DNS elsewhere, and so on. If you can afford it, maintain another ready copy of the site at a different provider.
Chris
The fact is, that would be a very poor goal. It's something we actively don't want to do, unless someone else is providing the resources to do it.
We have to balance the needs of quite a lot of different sorts of users. Matching all of the MIDI functionality found in Cubase may make an ideal program for some users, but if we spent all our time doing that, we'd be so behind on other features as to have a program that was useless for most of the people who want to use it now, including all of the developers who caused the project to happen in the first place.
This thread has so far followed the pattern of having one poster or another pronounce that Rosegarden "must" support feature X before it can even be considered 1.0, followed by Guillaume replying half-apologetically to say that we'd love to do that if we could find the time. The plain fact is that we've taken the decision that most of these things are not essential 1.0 features. And there's no reason we should apologise for that. You can disagree with particular instances -- clearly you do, and we'd encourage you to make feature requests with use cases so that we, and other developers, can take them into account when prioritising work in the future. But it's absurd to imply that a program isn't a worthwhile program at all because it doesn't do a particular feature that you personally want. That way lies madness, and/or Mozilla. Far better to accept that there is room for more than one program out there.
No, you can print directly from Rosegarden as well. The results won't compete with Lilypond, but they're readable.
You said,
The GPL [...] only requires that you provides [the source] on request to the to the user of your software
and then,
So you should re-read section 3. I'm refering to option b).
[...] b) Accompany it with a written offer [...] to give any third party [...] a complete machine-readable copy of the corresponding source code,
So which part of "any third party" were you having trouble with?
Yes.
The GPL [...] only requires that you provides [the source] on request to the to the user of your software
No.
Depends how you distribute your software. Section 3(b) of the GPL (which only applies if the source is not included with the original object distribution) does indeed require source to be available to anyone, and for no more than a nominal fee.
In any case, so long as I can get your source code free, legally, from anyone you distributed it to, then for consumer applications at least your software is effectively free. As, in practice, GPL software is.
This doesn't mean I particularly agree that the GPL causes the situation in which it's hard to charge directly for software applications. Other comments here have pointed out (a) that it was always hard to make money selling software directly to consumers and (b) that few consumers pay anything much for proprietary software either, any more. The model in which you distribute free software and sell the services around it is only a formalisation of the way that most proprietary business software generates most of its revenue anyway.
"Free Software" refers to freedom, not price.
I really wish the author of the article has addressed this particular myth as well. Reading the article, I could already see legions of Slashdot comments dismissing the whole argument on the grounds that "Free Software refers to freedom".
The plain fact is that Free Software does indeed appear in practice to be always free in terms of price. (Or effectively so, in the case of e.g. Linux distributions with several thousand packages for USD50 or less -- rates at which there's no way an individual author can get any financial benefit.) The GPL even ensures that software will be close to free of price by mandating that anyone can get the source code and build it themselves for no more than a nominal distribution fee.
Indeed, look at your own example -- a business selling a database product may choose to release it as free software, and offer a gratis download. So their software is free of price. Your example doesn't even illustrate the point you're trying to make: why is that? Because there are no examples that do?
Regardless of the moral intention of the GPL (and I largely approve of it and use it for my own work), it's stupid to dismiss the fact that GPL software is almost always free of price simply by saying that in theory it need not be so. Unless you can show some application of your theory in the form of a workable way of charging profitably for the actual software (rather than services around the software), then your argument is perhaps interesting, perhaps relevant somewhere else -- but not relevant here.
Oh, the usual reasons. MOTU don't want their cards to work with Linux, probably because they have a big investment in dedicated software to go with their hardware on other platforms. They won't release specifications, and they've been actively hostile towards any approach from developers offering to support them for free.
Well, they're both audio and MIDI sequencers for Linux. They both support outboard MIDI gear, native Linux ALSA soft synths, and audio and transport synchronisation through JACK. Both look and feel somewhat like the big sequencers for other platforms. Both use Qt for their GUIs, though Rosegarden also uses the KDE libraries. I happen to think Rosegarden has the more polished GUI, but I'm biased (see disclaimer at bottom).
Both support arbitrary numbers of MIDI and audio tracks, with audio mixing and routing capabilities. Both support LADSPA effects plugins, of which there are hundreds available free. Both can (with some work!) be made to use VST effects through vstserver. MusE can host VST instruments with libfst using Wine; either of them can drive VST instruments hosted separately using jack_fst. None of these VST solutions is currently at all easy to configure and build, but see here for more information. Rosegarden is implementing the DSSI synth API and will probably ultimately use a DSSI wrapper for VST instruments. Rosegarden can also be run without audio support if you only want MIDI or score, whereas MusE always requires JACK.
My rather fuzzy impression of the difference in "feel" between them is that MusE feels like it came more from a studio/MIDI gearhead background, Rosegarden more from a composition background. MusE is a bit further ahead with things like instrument plugins, audio routing (send/returns etc) and automation. Rosegarden places a lot more emphasis on the score editor, whereas the one that used to be in MusE was actually removed completely for the 0.7 release.
Rosegarden is a somewhat bigger and more complicated program than MusE (c 200K lines of code vs 130K LOC), which you may see as good or bad depending on whether the extra code happens to do stuff you want or not. They're both written in C++, should you happen to care.
On the subject of soundcard support: the usual quick answer is "it's probably supported unless it's FireWire or made by MOTU". In particular the current M-Audio, Terratec and RME semi-pro gear mostly works fine, as well as most consumer cards. The lack of FireWire audio device support currently is a pain though. Anyway, see the ALSA soundcard matrix for detailed information.
(Disclaimer: I am a Rosegarden developer and, although I track MusE CVS, I have never actually managed to get MusE 0.7 to build because I don't have the right libraries and autotools. So do take all this with a pinch of salt.)
9wm is a nice window manager, the first one I ever saw that was both complete enough to use and simply and clearly enough coded to understand -- the earlier twm and uwm have really nasty code in comparison. I was shocked to read elsewhere in this thread that 9wm's author (David Hogan) had died recently.
9wm was the basis for both lwm and my own wm2, which were two other early self-consciously minimal window managers (wm2 was first released in 1996).
Oh, and:
head over to CPDL or www.lightandmatter.org
Are the PDF examples on the latter using the standard Finale font? Now that is nasty. There's certainly right and wrong there. Too round, and the stems don't look properly attached. No balance. If the others are Garamond and Plantin, that's Arial.
For example, most fonts get the half-notehead wrong; that should be diamond shaped, not elliptical.
I take it you're saying that the line that forms the inside of the notehead should consist of two parallel (almost) straight strokes connected by curves, rather than a single ellipse?
In that case you probably did RC, for the Amadeus font certainly uses an ellipse. I'm not persuaded that there's any right or wrong there, though -- it's surely a question of taste. Yours is more like an old Garamond, theirs more like Plantin. I think theirs looks friendlier, feta looks more formal. I've seen far worse than both in printed scores, anyway.
Don't know about the smartmusic files (send me one, and I'll have a look)
They don't like to serve them to you if they can't detect their plugin. I'll have to take a closer look at the page source.
IIRC, the music font sucks
I think you might not RC, given the example (an opera score) I have in front of me at the moment, which looks fantastic.
Not that this is of much practical use to the average poverty-stricken Linux user.
I just went to Coda's website to see if I could see some examples of Finale output in PDF or whatever, and all I could find was a bunch of things that call for "the SmartMusic Viewer plug-in", which obviously I can't use. I guess it's the same idea as Sibelius's Scorch plugin, which I can't use either. Scorch uses the same file format as Sibelius proper, I believe; any idea whether these Finale SmartMusic files are the same format as the ETF files that Lilypond can import?
Well, at least it's pleasantly quiet around here now.
I do actually know one professional music typesetting company that uses Linux almost exclusively. They use a very old, rather expensive text-driven program called Amadeus. In many ways it sounds a bit like Lilypond to me, with I suspect rather more flexibility from years of being messed around with for a huge variety of score-like situations (books, exam texts, freeform jazz scores with wiggly lines everywhere etc). I see it's listed in the Other Packages section of the Lilypond website -- have you ever seen it?
I'm arriving very late here so probably nobody will read this, but... As one of the Rosegarden developers I can confirm that Rosegarden will never be quite comparable with Sibelius or Finale, because it's intended to be a compositional tool (that includes the best score capabilities we can manage) rather than a score-typesetting program.
But I can't agree that Linux has nothing to offer the professional typesetter. Sure, Linux doesn't have so much to offer the typesetter who wants to use a point-and-click interface, but for a professional who only typesets score (rather than composing it), a text-based interface like Lilypond's is arguably more productive anyway. It's ridiculous to describe Finale as somehow a "more professional" typesetting application than Lilypond; how "professional" this kind of application is depends entirely on the quality of the end results, and Finale is nothing very special there. Finale may be more useful to you, but more "professional"?
No, surely fdsa is right -- Lilypond doesn't really begin to address anything performance-related, and "performance-related" covers a vast amount of instrument, audio and interpretational stuff that a quick reference to samples doesn't begin to cover.
Lilypond can describe most of the data that a classical composer or a non-electronic performer would be interested in, but it's not a performance tool, which seems to be what "defining what note to play at what time with what instrument" is asking for. Lilypond and Csound squished together would be more like it, but only if you were happy to be working entirely in Csound synthesis.
Yes. There are lots of pieces of music software that are more or less comparable to LaTeX, in that they do specific tasks from the command-line and textual input: Csound for synthesis, SoX for audio manipulation, Lilypond for notation typesetting. They're all excellent pieces of software.
But I guess there aren't as many people who need to do only synthesis, audio manipulation, or notation typesetting as there are people wanting software that only typesets text. Music is always going to have more of a real-time, interactive nature.
Several of the "pure MIDI sequencers" actually have some level of audio support: MusE, Jazz++, Rosegarden-4 and Brahms at least do. It's all pretty damn basic at the moment, but there are a few interesting initiatives like JACK (an audio connection toolkit, used by things like Ardour -- we've just got the basics of support for it into Rosegarden) that might help to perk things up in the near future. I think once a few applications get able to talk to one another, we'll have far more interesting prospects.
Caveat: I don't actually understand any of this stuff, I'm a notation guy.
I think the community of linux-using music-making dsp-coding geeks with enough time and good taste to work on quality GUI applications probably is pretty small. Making GUIs is difficult and mostly not much fun; it doesn't fit well with the scratch-your-own-itch style of development, and you have to think about those users all the time. Infrastructure is hard too, but often not quite so damn tedious.
I work on the Rosegarden-4 project, which maybe one day will be "somewhat like" Logic. So far we have yet another half-decent sequencer with MIDI and a bit of audio plus reasonable notation support, and we could definitely use some help. But the potential is there, we're making good progress, and I'm quite excited about the infrastructure, which I really think is becoming good enough and consistent enough to support it.
Projects like DeMuDi surely are mostly a good thing. The software is slowly getting there, and a push towards making it easier to find and install all the bits and bobs you need can surely only help. (Except of course that this is exactly what the mainstream distributions should be doing anyway.)
The very ambitious Rosegarden-3 development progressed fastest when I was in a really dull job a year or more ago, but it's been painfully slow going since. The main problem is just building up enough of a base to make it worth anyone else's while trying to do anything with it. Still, I'm persevering; the eventual aim is a bit different from that of Denemo or Brahms (though GSeq is probably closer) so it seems worth sticking with it for the moment.
Anyway, see Rosegarden's homepage for some development notes and the mailing-list archive; and the 3.0 code and docs, such as they are, are on GNOME's CVS server.
Chris