You're very correct that it's hard to find a MIDI-only sequencer these days. I'm just trying to say that that's a *bad* thing.
Just because your telephone doesn't come with a built-in toaster doesn't mean it's any worse at being a phone. Certainly there are a least a few people out there who would benefit from being able to make toast while calling their friends, but that doesn't mean everyone who buys a phone should have to deal with a hybrid interface.
Sure, that's a silly example. But more subtly, not every phone comes with a built-in answering machine. You could argue that they should, because their uses are related and there is a certain amount of interface overlap. Still, the market has shown that not everyone wants a phone with an answering machine built-in, even if one is included for free. For example, if you had voice mail, then the built-in answering machine features of the hybrid phone unit would merely get in the way and take up extra space on your desk.
Of course, I wouldn't wish for hybrid systems to disappear entirely -- after all *some* users prefer them -- but I do wish there was still some choice in the market.
You make a lot of good points, too many for me to answer at once, so please bear with me.
First and foremost, I agree that your choice of tool will inevitably influence how you work and thus what you can produce. Even the various types of graphics programs you cite are not completely transparent in this regard. One side of me wants to argue that some types of applications impose less structure than others (for instance, a linear sequencer is less limiting than a tracker), but since they all make *some* sort of imposition, their relative limitations are entirely subjective.
I disagree though with the implication made by your boldfaced statement. Yes, software audio production is unintuitive (as discussed above), but it is not the involvement of software that makes it so. Hardware involvement is just as much of a problem. So is transcribing music into paper notation by hand. Any representation of music or audio other than what is mixed by our ears in realtime is unintuitive. I don't mean to be glib... Just as the relative intuitiveness of different software packages is a subjective matter, the relative intuitiveness of software versus hardware versus some other visual representation will depend on the individual user.
Onwards to niggling details. Software does not imply the use of a mouse or a QWERTY keyboard. Just as tablets (your own example) helped to make graphics software more intuitive to many artists, MIDI keyboards and knob/slider boards have helped to make music softare more intuitive to many musicians. Much of the MIDI filter software I write has no GUI interface at all (taking its entire set of controls through invocation arguments and through MIDI messages), yet it certainly performs a useful, musical task.
My objection to overintegration of loosely-related software comes from a penchant for mixing and matching. The idea of having to use an interface optimized for recording when I wish to chain MIDI-preprocessors, softsynths, and audio filters in a live performance (no recording in sight) bothers me greatly. Systems like Rewire and VST Link would be great if they were OS-level services, but their dependence on a master host application runs counter to my natural workflow. See above for "making the best of it anyway".
You may well be right that he needs both, but the fact that his past experience is made up of dedicated MIDI and hybrid programs doesn't mean that his future has to as well; after all, he wouldn't be asking for suggestions if he was happy with what he already had.
The effectiveness of a given user interface is very much a personal assessment, so if you find the likes of Sonar to be a natural environment then more power to you. With the exception of the new multitrack piano roll, I found Cakewalk a better editing environment for MIDI before it had the audio features added in; I've been using it since the DOS days. As an audio environment, I find it imprecise and awkward, which is why I'm looking around for a decoupled DAW.
Incorporating DAW and MIDI sequencing into the same application is certainly not the only way to achieve synchronization between them. MTC and SMPTE are well-established, widely supported standards for synchronizing separate programs or even separate hardware components. Every professional DAW has support for them already.
It boils down to the old Unix philosophy... as long as there is proper infrastructure to support intercomponent communications, then each application should be small and dedicated to a specific task. If a user likes the MIDI sequencer made by brand X but prefers the DAW made by brand Y, there's no reason why he should have to compromise. I tend to feel this way about every category of integrated software.
Groovemaneuver asked for recommendations about a specific subcategory of music software, the digital audio workstation. A DAW is generally defined as a multitrack audio recorder and editor, usually supporting a nondestructive editing model and some facility for applying audio effects. While MIDI sequencing and notation support may be found in some current DAW packages, they have very little to do with the DAW concept.
As such, ProTools, Nuendo, and Ardour are true DAWs, while Cubase, Logic, and Sonar are hybrid DAW/sequencers. Hybrids inherently have to make compromises between two sets of goals, and their interfaces usually suffer as a result of it. They might be better value for your money if you need both sets of features, but if you find them awkward to use, that might well be why.
An alternative to software DAWs is the standalone hardware variety, such as the Roland VS series. As dedicated hardware gear, they're less flexible, but have a more optimized interface which you might find gets in your way less. You can get used ones for the same cost as the software would be.
Sorry I can't recommend a particular package; I'm in the process of looking as well. I will say that Sonar is stronger in its MIDI sequencing features than its DAW ones.
Whatever the intentions of Bash's authors with regard to "embrace and extend" tactics, it can be used perfectly safely, and may well be convenient for the poster.
Bash is one of those programs which acts differently depending on the filename of its executable. When invoked from a copy or a link named/bin/sh, it emulates the traditional Bourne shell without GNU extensions.
Thus, always write your scripts with the traditional #!/bin/sh shebang. If Bash is masquerading as Bourne, it won't hurt you that way. You can still benefit from Bash's extensions for interactive use (such as command editing and history) by setting your shell to/bin/bash via chsh.
MPEG Layer 3 Audio is fundamentally a compression algorithm, not a file format. While it is most often used with the particular set of headers and packaging that make up an "MP3" file, it does not have to be.
Microsoft WAV files can contain audio in any of several dozen different formats. The most common format is uncompressed "PCM" audio, but by setting the right flags in the header, various compression schemes can be used instead. One of the more recent compression algorithms to be supported in WAV files is MPEG Layer 3.
Would it be a valid option to have a downloadable, single-file, native executable which runs from the temp dir without any installation? You know, click on the link and say "run" instead of "save".
If so, you have plenty of options for how to write your program. GUI libraries with support for multiple platforms are common (wxWindows, for example), or you can use an interpreted language which has support for packaging the script and the interpreter together into a single executable file (such as Tcl/Tk).
You might be pleased to learn about PLT Scheme, a free, cross-platform Scheme implementation with a GUI kit based on [a somewhat old version of] wxWindows.
A common problem when it comes to searching PDFs is when they contain pictures of text rather than the text itself. Depending on how the PDF was generated, the document might look perfect to the human eye, but be very difficult for the reader program to manipulate as text. PDFs generated from LaTeX have proven difficult in this regard before, so beware of using them as your test metric!
I know this is offtopic, but Markus doesn't have an email address posted. Please forgive me.
> "DEG DED {DE}F ED CBCA..." (George Gershwin)
This signature has been bothering me for months. The theme sounded familiar, but I couldn't quite place it. Finally, I found it about a third of the way through the Rhapsody in Blue. The reason I didn't get it right away was I was humming the wrong rhythm. It would be a lot easier to identify if you weren't missing a note! Try "DEGG DED {DE}F ED CBCA..." or better still "DEGG-DEDF---ED--CBCA".
Many of the paradoxes / plot holes can be eliminated if you subscribe to the inertial theory of history modified via time travel. Loosely stated, if a time traveller engages in some action that changes history, then (1) the change does not propogate forwards through history immediately, but rather over a span of time proportional to the severity of the change; and (2) history automatically rearranges itself so as to keep the change localized in effect rather than propogating out infinitely, again proportional to the severity of the change. Of course this is all utter BS, but my friends and I have found that it helps make time travel fiction much easier to swallow.:-) There are some hints in BTTF that the author also subscribed to this theory, such as the slowly disappearing photograph in Part 1.
People who fear that a switch from US-ASCII to UTF-8 will break their existing programs should really read the Bell Labs document linked above, section 2.3 of the Unicode spec, or RFC 2044. UTF-8 was designed very carefully to make life extremely easy for people making that exact migration. There are amazingly few circumstances where it even matters that it is variable width. Those people who are suggesting UCS-2, UCS-4, etc. as alternatives in order to solve the nonexistant problem of UTF-8's variable width nature should really take a closer look at it.
Re:I was shocked that I couldn't find a Go board.
on
Low Tech Toys?
·
· Score: 2
I didn't say I disagreed with you. I was just amused by your example.
Re:I was shocked that I couldn't find a Go board.
on
Low Tech Toys?
·
· Score: 2
Anyone else find it amusing that he's complaining that the makers of a game called "Monopoly" exploit their monopoly on it?
As someone who does know what pthreads are and uses them frequently in a professional setting, I would recommend the O'Reilly book mentioned above. It contains a decent introduction to threading in general, a healthy dose of usage scenarios with detailed explanations, and a programmers' reference. If I remember correctly, it was written by some of the folks at DEC who designed most of the pthreads standard and wrote the first implementation. However, although it does a nice job of explaining the difference between threads and forked processes, it does not attempt to make any bias-free recommendations as to when forked processes might be more appropriate for a task.
Have you tried CSound? Free, open source, ported to just about every platform, driver, and plug-in architecture; supports just about every synthesis technique ever invented; supports arbitrary combinations of realtime and batch processing of both input and output; etc. The downside... an archaic programmatic interface rather than a flashy GUI one. It's very, very powerful, but the learning curve is steep.
In spite of their obviously different backgrounds -- Buzz comes from the MOD tracker community, whereas CSound comes from the 1960's academic synthesis community -- there has been a surprising amount of convergence between them, to the point that they now can compete for the same niche.
This has been mentioned ad nauseum on Slashdot already, but it seems to be missing in this article... if you're really interested in using Linux for sound and music, the definitive place to go is Dave Phillip's comprehensive directory.
This is a very important point about software-based synthesizers and samplers. While many are quite capable of producing wonderful sounds, latency is a very big issue if you plan to play them in realtime. Running on a well-spec'ed machine will help (including processor speed, amount of memory, disk speed, sound card model, and sound card driver), but I have only heard rumors of a setup where lag is imperceptable, never experienced one.
I must disagree though with the claim that sequencers are interchangable, commodity software. As the centerpiece of the composing and editing environment, it is very important to choose one which has a feature set and interface which matches your needs. While many features overlap between the competing professional packages (Cakewalk, Cubase, Logic, Performer, Vision, and even ProTools), each one does things slightly differently and has different strengths.
To call the OSS sound driver architecure "the most mature around" would be extremely inaccurate. It is newer, less stable, and less documented than the MME sound driver architeture on Windows and the three or four competing sound driver architectures on the Mac. It might be arguable whether it is more mature than the newer DirectSound driver architecture on Windows, and it has indeed gotten more use so far than the brand new Core Audio sound driver architecture on MacOS/X. Comparing it to the NeXTStep Audiokit and the well-known sound architectures from BeOS and the Amiga is an interesting but at this stage merely academic exercise.
The news is not all bleak for audio on Linux though; the ALSA sound driver architecture is the relatively recent replacement for OSS, which is better designed, and makes a convincing competitor to sound architectures from other platforms.
Stellent (formerly INSO) Outside In is a popular commercial solution to the problem. It is an SDK for conversion of lots of document types (including Word) into plaintext, HTML, or XML. Its allows you to control how much of the formatting is preserved, and in what manner. It's not perfect, not crash-proof, and not free, but it might do the trick in a corporate situation, especially when wrapped with a watchdog process. My company has had a lot of success with it.
I'm so disappointed to hear this. As an incurable Model M bigot (indeed, typing at one right now), I've been recommending pckeyboard.com to people without having actually purchased any from them myself.
Now I'll just tell people to do what I do... buy the original IBM-branded ones used at computer shows. There are always some for sale cheap, and since they're damn near indestructable, they're a safe buy.
Re:I remember when it was the best...
on
Altavista Renewed
·
· Score: 2
A lesson from Search Engines 101:
Most search engines, including Google and AltaVista, are word-based reverse-indexes at heart. This is like the index at the back of a book; it is optimized for looking up a single word and getting back a list of pages in which the word occurs. It is prohibitively inefficient at looking for substrings which don't line up with word boundaries. Since this latter concept lies at the core of regular expressions, they are incompatible with reverse-indexes for all practical purposes. (Using only the index of a book, try to find all occurances of the regular expression ".*foo".) As such, don't expect to see them on AltaVista or Google all that soon.
In spite of the hasty moderation, this is not a bad suggestion at all. Captain Pedantic was suggesting to use tar in the mode which writes directly to the disk without any filesystem. Tar has this ability primarily so that it can write to tapes, which don't have filesystems, but it can be used with any device. Since tar uses the same format on both OSes (or at least GNU tar does, which is available for both), the data should be available to both. Plus, tar works well with big files. The big drawback is that this will only work for backing up and restoring; you can't use the files directly from the disk with any program other than tar.
Slashdot Mirror
> using the middle button to scroll doesn't work in Mozilla
If you're looking for this feature in a Mozilla derived browser, try Phoenix/Firebird. It does it very nicely.
You're very correct that it's hard to find a MIDI-only sequencer these days. I'm just trying to say that that's a *bad* thing.
Just because your telephone doesn't come with a built-in toaster doesn't mean it's any worse at being a phone. Certainly there are a least a few people out there who would benefit from being able to make toast while calling their friends, but that doesn't mean everyone who buys a phone should have to deal with a hybrid interface.
Sure, that's a silly example. But more subtly, not every phone comes with a built-in answering machine. You could argue that they should, because their uses are related and there is a certain amount of interface overlap. Still, the market has shown that not everyone wants a phone with an answering machine built-in, even if one is included for free. For example, if you had voice mail, then the built-in answering machine features of the hybrid phone unit would merely get in the way and take up extra space on your desk.
Of course, I wouldn't wish for hybrid systems to disappear entirely -- after all *some* users prefer them -- but I do wish there was still some choice in the market.
You make a lot of good points, too many for me to answer at once, so please bear with me.
First and foremost, I agree that your choice of tool will inevitably influence how you work and thus what you can produce. Even the various types of graphics programs you cite are not completely transparent in this regard. One side of me wants to argue that some types of applications impose less structure than others (for instance, a linear sequencer is less limiting than a tracker), but since they all make *some* sort of imposition, their relative limitations are entirely subjective.
I disagree though with the implication made by your boldfaced statement. Yes, software audio production is unintuitive (as discussed above), but it is not the involvement of software that makes it so. Hardware involvement is just as much of a problem. So is transcribing music into paper notation by hand. Any representation of music or audio other than what is mixed by our ears in realtime is unintuitive. I don't mean to be glib... Just as the relative intuitiveness of different software packages is a subjective matter, the relative intuitiveness of software versus hardware versus some other visual representation will depend on the individual user.
Onwards to niggling details. Software does not imply the use of a mouse or a QWERTY keyboard. Just as tablets (your own example) helped to make graphics software more intuitive to many artists, MIDI keyboards and knob/slider boards have helped to make music softare more intuitive to many musicians. Much of the MIDI filter software I write has no GUI interface at all (taking its entire set of controls through invocation arguments and through MIDI messages), yet it certainly performs a useful, musical task.
My objection to overintegration of loosely-related software comes from a penchant for mixing and matching. The idea of having to use an interface optimized for recording when I wish to chain MIDI-preprocessors, softsynths, and audio filters in a live performance (no recording in sight) bothers me greatly. Systems like Rewire and VST Link would be great if they were OS-level services, but their dependence on a master host application runs counter to my natural workflow. See above for "making the best of it anyway".
You may well be right that he needs both, but the fact that his past experience is made up of dedicated MIDI and hybrid programs doesn't mean that his future has to as well; after all, he wouldn't be asking for suggestions if he was happy with what he already had.
The effectiveness of a given user interface is very much a personal assessment, so if you find the likes of Sonar to be a natural environment then more power to you. With the exception of the new multitrack piano roll, I found Cakewalk a better editing environment for MIDI before it had the audio features added in; I've been using it since the DOS days. As an audio environment, I find it imprecise and awkward, which is why I'm looking around for a decoupled DAW.
Incorporating DAW and MIDI sequencing into the same application is certainly not the only way to achieve synchronization between them. MTC and SMPTE are well-established, widely supported standards for synchronizing separate programs or even separate hardware components. Every professional DAW has support for them already.
It boils down to the old Unix philosophy... as long as there is proper infrastructure to support intercomponent communications, then each application should be small and dedicated to a specific task. If a user likes the MIDI sequencer made by brand X but prefers the DAW made by brand Y, there's no reason why he should have to compromise. I tend to feel this way about every category of integrated software.
Groovemaneuver asked for recommendations about a specific subcategory of music software, the digital audio workstation. A DAW is generally defined as a multitrack audio recorder and editor, usually supporting a nondestructive editing model and some facility for applying audio effects. While MIDI sequencing and notation support may be found in some current DAW packages, they have very little to do with the DAW concept.
As such, ProTools, Nuendo, and Ardour are true DAWs, while Cubase, Logic, and Sonar are hybrid DAW/sequencers. Hybrids inherently have to make compromises between two sets of goals, and their interfaces usually suffer as a result of it. They might be better value for your money if you need both sets of features, but if you find them awkward to use, that might well be why.
An alternative to software DAWs is the standalone hardware variety, such as the Roland VS series. As dedicated hardware gear, they're less flexible, but have a more optimized interface which you might find gets in your way less. You can get used ones for the same cost as the software would be.
Sorry I can't recommend a particular package; I'm in the process of looking as well. I will say that Sonar is stronger in its MIDI sequencing features than its DAW ones.
Whatever the intentions of Bash's authors with regard to "embrace and extend" tactics, it can be used perfectly safely, and may well be convenient for the poster.
Bash is one of those programs which acts differently depending on the filename of its executable. When invoked from a copy or a link named /bin/sh, it emulates the traditional Bourne shell without GNU extensions.
Thus, always write your scripts with the traditional #!/bin/sh shebang. If Bash is masquerading as Bourne, it won't hurt you that way. You can still benefit from Bash's extensions for interactive use (such as command editing and history) by setting your shell to /bin/bash via chsh.
I can explain the concept of MP3 in a WAV file.
MPEG Layer 3 Audio is fundamentally a compression algorithm, not a file format. While it is most often used with the particular set of headers and packaging that make up an "MP3" file, it does not have to be.
Microsoft WAV files can contain audio in any of several dozen different formats. The most common format is uncompressed "PCM" audio, but by setting the right flags in the header, various compression schemes can be used instead. One of the more recent compression algorithms to be supported in WAV files is MPEG Layer 3.
Tada!
Would it be a valid option to have a downloadable, single-file, native executable which runs from the temp dir without any installation? You know, click on the link and say "run" instead of "save".
If so, you have plenty of options for how to write your program. GUI libraries with support for multiple platforms are common (wxWindows, for example), or you can use an interpreted language which has support for packaging the script and the interpreter together into a single executable file (such as Tcl/Tk).
You might be pleased to learn about PLT Scheme, a free, cross-platform Scheme implementation with a GUI kit based on [a somewhat old version of] wxWindows.
A common problem when it comes to searching PDFs is when they contain pictures of text rather than the text itself. Depending on how the PDF was generated, the document might look perfect to the human eye, but be very difficult for the reader program to manipulate as text. PDFs generated from LaTeX have proven difficult in this regard before, so beware of using them as your test metric!
I know this is offtopic, but Markus doesn't have an email address posted. Please forgive me.
> "DEG DED {DE}F ED CBCA..." (George Gershwin)
This signature has been bothering me for months. The theme sounded familiar, but I couldn't quite place it. Finally, I found it about a third of the way through the Rhapsody in Blue. The reason I didn't get it right away was I was humming the wrong rhythm. It would be a lot easier to identify if you weren't missing a note! Try "DEGG DED {DE}F ED CBCA..." or better still "DEGG-DEDF---ED--CBCA".
Musically,
Div.
Many of the paradoxes / plot holes can be eliminated if you subscribe to the inertial theory of history modified via time travel. Loosely stated, if a time traveller engages in some action that changes history, then (1) the change does not propogate forwards through history immediately, but rather over a span of time proportional to the severity of the change; and (2) history automatically rearranges itself so as to keep the change localized in effect rather than propogating out infinitely, again proportional to the severity of the change. Of course this is all utter BS, but my friends and I have found that it helps make time travel fiction much easier to swallow. :-) There are some hints in BTTF that the author also subscribed to this theory, such as the slowly disappearing photograph in Part 1.
People who fear that a switch from US-ASCII to UTF-8 will break their existing programs should really read the Bell Labs document linked above, section 2.3 of the Unicode spec, or RFC 2044. UTF-8 was designed very carefully to make life extremely easy for people making that exact migration. There are amazingly few circumstances where it even matters that it is variable width. Those people who are suggesting UCS-2, UCS-4, etc. as alternatives in order to solve the nonexistant problem of UTF-8's variable width nature should really take a closer look at it.
I didn't say I disagreed with you. I was just amused by your example.
Anyone else find it amusing that he's complaining that the makers of a game called "Monopoly" exploit their monopoly on it?
As someone who does know what pthreads are and uses them frequently in a professional setting, I would recommend the O'Reilly book mentioned above. It contains a decent introduction to threading in general, a healthy dose of usage scenarios with detailed explanations, and a programmers' reference. If I remember correctly, it was written by some of the folks at DEC who designed most of the pthreads standard and wrote the first implementation. However, although it does a nice job of explaining the difference between threads and forked processes, it does not attempt to make any bias-free recommendations as to when forked processes might be more appropriate for a task.
I didn't mean to be too negative; it is quite useful, in spite of certain shortcomings.
In spite of their obviously different backgrounds -- Buzz comes from the MOD tracker community, whereas CSound comes from the 1960's academic synthesis community -- there has been a surprising amount of convergence between them, to the point that they now can compete for the same niche.
This has been mentioned ad nauseum on Slashdot already, but it seems to be missing in this article... if you're really interested in using Linux for sound and music, the definitive place to go is Dave Phillip's comprehensive directory.
This is a very important point about software-based synthesizers and samplers. While many are quite capable of producing wonderful sounds, latency is a very big issue if you plan to play them in realtime. Running on a well-spec'ed machine will help (including processor speed, amount of memory, disk speed, sound card model, and sound card driver), but I have only heard rumors of a setup where lag is imperceptable, never experienced one.
I must disagree though with the claim that sequencers are interchangable, commodity software. As the centerpiece of the composing and editing environment, it is very important to choose one which has a feature set and interface which matches your needs. While many features overlap between the competing professional packages (Cakewalk, Cubase, Logic, Performer, Vision, and even ProTools), each one does things slightly differently and has different strengths.
To call the OSS sound driver architecure "the most mature around" would be extremely inaccurate. It is newer, less stable, and less documented than the MME sound driver architeture on Windows and the three or four competing sound driver architectures on the Mac. It might be arguable whether it is more mature than the newer DirectSound driver architecture on Windows, and it has indeed gotten more use so far than the brand new Core Audio sound driver architecture on MacOS/X. Comparing it to the NeXTStep Audiokit and the well-known sound architectures from BeOS and the Amiga is an interesting but at this stage merely academic exercise.
:-)
The news is not all bleak for audio on Linux though; the ALSA sound driver architecture is the relatively recent replacement for OSS, which is better designed, and makes a convincing competitor to sound architectures from other platforms.
In short, mind your superlatives!
Stellent (formerly INSO) Outside In is a popular commercial solution to the problem. It is an SDK for conversion of lots of document types (including Word) into plaintext, HTML, or XML. Its allows you to control how much of the formatting is preserved, and in what manner. It's not perfect, not crash-proof, and not free, but it might do the trick in a corporate situation, especially when wrapped with a watchdog process. My company has had a lot of success with it.
I'm so disappointed to hear this. As an incurable Model M bigot (indeed, typing at one right now), I've been recommending pckeyboard.com to people without having actually purchased any from them myself.
Now I'll just tell people to do what I do... buy the original IBM-branded ones used at computer shows. There are always some for sale cheap, and since they're damn near indestructable, they're a safe buy.
A lesson from Search Engines 101:
Most search engines, including Google and AltaVista, are word-based reverse-indexes at heart. This is like the index at the back of a book; it is optimized for looking up a single word and getting back a list of pages in which the word occurs. It is prohibitively inefficient at looking for substrings which don't line up with word boundaries. Since this latter concept lies at the core of regular expressions, they are incompatible with reverse-indexes for all practical purposes. (Using only the index of a book, try to find all occurances of the regular expression ".*foo".) As such, don't expect to see them on AltaVista or Google all that soon.
In spite of the hasty moderation, this is not a bad suggestion at all. Captain Pedantic was suggesting to use tar in the mode which writes directly to the disk without any filesystem. Tar has this ability primarily so that it can write to tapes, which don't have filesystems, but it can be used with any device. Since tar uses the same format on both OSes (or at least GNU tar does, which is available for both), the data should be available to both. Plus, tar works well with big files. The big drawback is that this will only work for backing up and restoring; you can't use the files directly from the disk with any program other than tar.