One would hope that the patent review will also ensure an in-depth audit of any alternative operating systems and applications software for issues present there. And if that can't be done, then a clear statement that it is not possible to establish the patent risk of using the alternatives.
all true. but here's my favorite story for this department. pro-audio-engineer but non-computer user buys Digital Performer and a G5. installs RME hammerfall. tries to record 8 tracks straight in from an ADAT.
there's no audio signal.
to test, user drags audio file into session. cool, region appears. test playback. no signal and no meters. no amount of anything will produce output.
user switches to builtin audio. still no output.
2hrs later, after a support phone call, it is revealed that regions derived from files whose SR differs from the session will be silent. no visual indication or warning of this is ever given in the main editor window.
this is from a product judged to be one of the big 4 or 5... the user has had this system for nearly a year and has still never actually used it.
there is no notion of "opening" an existing file, because ardour isn't
a soundfile editor. you work with sessions, which may contain hundreds
or thousands or files (or just one, if you wish). so the first thing
you have to do, as indicated by the big message in the editor window,
is to create a new session (Session->New).
because ardour (like other DAWs) uses a track-based metaphor, you then
have to create 1 or more tracks in which to place the audio you want
to work with. in anything less than current CVS, Session->Add Track,
then you can use the context menu for the track to embed an external
soundfile. alternatively, click on the "title bar" of the region list,
and use the menu to import (ie. copy and convert to native format) or
embed (ie. link to and use as-is) existing audio files.
with current CVS you can simply drag-n-drop an audio file from
nautilus etc. (in any format
understood by libsndfile) into the editor window (the big blank
area), and ardour will create appropriately configured tracks for
you.
we've played with the idea of having a default session when you start
up ardour. but its rather hard, because a session is a directory, not
a single file, and figuring out how to handle "save" operations before
the location is defined (there are several auto-save points that you
can't avoid) is rather tricky.
as for what it can do that your current tools don't: if you're using
soundfile editors like audacity, there is no notion of "region based"
editing. ardour's editor is completely non-linear and completely
non-destructive and it operates on units of informations (regions) that
are assumed to have some semantic significance. metaphorically, you
are laying out audio (and later MIDI and OSC) on a "canvas", not
slicing and dicing the contents of a single file. it has also been my
experience that most soundfile editors do not offer musical time axes,
which for most "musical" editing can be deeply problematic. sequencers
like rosegarden and muse obviously do, and they offer some of ardour's
audio features, but a tiny subset of the set of things that ProTools
users always present me with when they say "I bet Ardour doesn't do...".
that's ignoring all manner of other things related to its highly
evolved mixer architecture and signal routing possibilities.
recouping the costs over 4-5 years has never been the goal. just making a modest living continuing to do this kind of work is.
the manual is not the only element in the revenue strategy - i would be stupid if i believed that could ever work. but its a significant element. i've already been approached by another moderately well-known open source-related publisher about doing the manual as "a book".
the main point of me doing the manual is to give people something tangible when they pay to get ardour. sure, there might be others (c.f. craig anderton's endless list of books on cubase, sonar etc), but this is the one you can pay for and feel good about doing so:)
the full revenue model involves the manual, sponsorship, contract work, partnerships, support, donations and possibly grants.
btw, monty may be a pro engineer. but the forums for proprietary DAWs are full of comments from people who are "pro engineers" who can't figure out how to do basic stuff. this is not unique to ardour. DAWs are probably among the most complex software used by a single person, and its certainly the most complex thing i've ever been involved with (much more complex, say, than telephone switching software).
do you know why Protools looks the way it does? because they have hundreds of beta testers and serious users offering them feedback at every step of their game. there isn't one thing in PT that hasn't been driven by user feedback - that may be good or bad, but it does mean that the UI is driven by user demands.
second, there is no "MS world" here - the flagship DAWs all started life on the Mac. hell, 4 years ago, PT was only certified to run on a *single* intel-based system (from IBM).
third, DAWs have all pretty much converged on the exact same feature set. you could feel that in the air at NAMM this year - nobody knows where to go next (well, the ardour project does, but it will be a while before we do). ardour attempts to get the best ideas from all of them, so although our UI is structured roughly like PT, we include the new "editor-window-mixer-strip" that originated in SX and is now in Sonar as well.
i'm not sure its worth going into this here, since monty and i have shared our fair share of flames and discussions on irc.
all i can say right now is that i don't like the fact that we have no manual, but that i have worked my ass off on this project for 4 years, and there is a limit to what i can do. and because i want to use the blender model (software: $$ free, manual: revenue source), its not really feasible for other people to write The Manual. however, i can't stop other people from writing manuals. strangely, though, from all the complaints about the opaque functionality, no such manuals have emerged. perhaps people really want me to make a living from this thing after all...
as for "a million buttons", we have less buttons than protools and samplitude, so that can hardly be a central issue. if you don't like the colors, you can change them without recompiling, or you could pay or otherwise convince someone to do a new GTK theme (an alternative one already exists that may become the default for 1.0).
i would love to see ardour be simpler for new users to just walk in and start using. but i am more concerned that the software architecture is adequate for the extraordinary things that a DAW is expected to do. as my confidence in that grows, actually writing the manual starts to make more and more sense.
and yes, ardour's bias has been towards *recording* audio because i wrote it as a tool for use recording studios. it has slowly started to adopt more functionality when it comes to handling existing audio files, including (these days) full support for drag-n-drop direct from nautilus and similar file system browsers.
finally, we have lots of new users who stop by the #ardour IRC channel and get lots of help from everyone including pro-users, other new users, experienced users and the core developers. the majority of them get things figured out pretty quickly and then seem quite happy. not the best possible "new user" experience, but not the worst either.
audacity is a soundfile editor, ardour is a digital audio workstation. you can do some of the same things in each - record audio, chop it up, apply FX and so forth - but they are not equivalent in a deeper sense.
ardour is modelled on proaudio apps like protools, nuendo and samplitude. its not intended to be used for simple editing tasks, but for complex multi-track, multi-channel audio work. we hope that its UI will evolve to make the simple stuff simple, but our initial goal has been to make sure we have an internal architecture that can do anything the high-end proprietary apps can do, and more.
if you don't know how the high-end tools work, ardour will seem very very complex (and the current lack of a manual won't help much with that). if you have used protools, ardour will seem relatively familiar to you, although we attempt to take best-of-breed features from all the other DAWs. otoh, DAWs have all pretty converged on the same core feature set, so the differences have more to do with GUI nuances than functionality.
there is no POSIX call to wait on a mutex *AND* a change in the state of a file descriptor. you can't wait on different kinds of events at all (semaphores, file descriptors, mutexes, signals). its bad.
jmusic has nothing on the facilities offered by the programs mentioned in the parent. PD is an incredible environment for experimental music composition.
No, if you want an analogy in the audio domain, SVG is closer to MPEG4-SA (Structured Audio). It contains both instructions on how to make the sounds, and on when to make them. SAOL is the most well-formed implementation of MPEG4-SA so far.
I am JACK's primary author. I hope I can explain some of the basics to
you.
1. What the hell is a signal graph (re: your response above)? Of what
I've read about JACK, that's the first time I've seen that
expression? Or by "signal graph" do you simply mean "a graphical
environment for stringing together a sequence of signal processing
modules into an overall application"?
When audio programmers talk about a signal graph, they are using the
term to refer to a rather abstract conceptualization of what is
happening in software (sometimes in hardware). The model is of a
series of "nodes" each of which processes a signal in some way. Each
node is connected to one or more other nodes, for input and/or
output. You can build a very simple graph, such as some kind of node
that reads from a disk file and sends output to another node that
delivers it to an audio interface. Or you can build incredibly complex
graphs in which the signal is routed all over the place, possibly even
including through feedback loops.
JACK is merely one of many systems that use the model of a signal
graph internally; GStreamer is another.
2. You say that JACK is for communications between different
processes. My understanding was that JACK was for communication
between different sources/sinks of audio signal. Those could be
processes, but they could also be hardware devices. For instance,
when I start jackd prior to running rosegarden4, I tell it to use
the ALSA driver for output. In fact, I thought that it could really
be anything that could provide or accept an audio signal (even
files, network URLs, etc.), since some sort of "virtual device"
could be specified for them. Is that not correct? And if it is
correct, how is that different from Gstreamer then?
Gstreamer is really a toolbox to be used by a SINGLE program
to construct processing pathways (aka "signal graphs"). It offers no
facilities (other than connections to JACK) that allow
MULTIPLE processes to route data among themselves.
As to what a JACK client does with the data it receives - that is
entirely up to the client. We have some clients that stream to an
icecast server, other people are working on UDP and RTP-based
networking, others write data to disk etc. But JACK knows nothing
about this, its entirely internally to each JACK client.
3. What do you mean by "with Gstreamer the whole graph is in-process"?
Are you saying that you use the graphical signal path editor to
create an application out of modules, but when you're done it links
(in the post-compilation sense) the modules together into a single
executable which has the capability described by the network?
Because otherwise -- if the modules do their work independently and
pass data between each other -- that sounds like processes talking
to processes, just like with JACK. What am I missing?
As I mentioned above, Gstreamer is used by a SINGLE application to
build processing pathways. It is of no use whatsoever in building
multiprocess pathways, other than its connection to JACK.
4. My understanding of the whole point of JACK is that it's for
low-latency audio work. But it sits between processes, or between
devices and processes, or whatever; how can that be lower-latency
than if JACK wasn't there at all. For example, rosegarden4 uses
JACK to pass data to the ALSA driver for my soundcard. How can that
be lower-latency than if rosegarden4 just talked to the ALSA driver
directly?
For a situation involving only one process (such as rosegarden),
its certainly possible for direct access to provide marginally lower
latencies than with JACK. But when I say "marginal", I really mean
it. On a modern CPU, and with the right kernel, you can basically JACK
as low as your audio interface can handle. The reason that JACK's
design matters for latency is 2-fold. First of all, it
imposes the correct model of int
does anybody believe that the "SMP" used in reference to the French Telecom DB means "symbol manipulation program" rather than "symmetric multiprocessing"? how are we supposed to take seriously a study (or at least a report about the study) where they just look up acronyms with no understanding?
because most pro-audio apps use floating point as the basic representation of audio samples, and the athlon wipes the floor in terms of FP performance. intel chips not only have worse FP performance, they have an unbelievably bad problem with denormals that can cause code to slow down by factors of 4-100.
cubase sx has already been ported to linux.
steinberg see no market for it. keep in mind that neundo (which is where the technology inside sx originates) was first written for irix...
why do you think it was the machine god that defeated smith? why not the idea that neo needed smith to "take over" himself so that he could (neo) could take control of smith, analogous to what neo did in the first movie. by the time smith sees the error of his move, its too late. the machine god didn't disagree with neo when neo said "you cannot stop him, but i can". neo is the only one with the power to stop smith, but smith has to do his "takeover" first...
the architect did not say that. the oracle asked him if the others who wanted out would be released. she never said humans. she could just as easily have meant other programs in the same situation as kadya.
smith was a threat because he had found a way to get out of the matrix in the real world. if he could take over humans, he could certainly take over machines.
still, its weak. one would think that taking over
machines would be easier for the machines to prevent.
neo had to allow smith to "take him over" before he could exert ultimate control and destroy neo. smith had to get "inside" neo before neo could exercise his ultimate choice. so to speak.
anybody have any thoughts on who the oracle was referring to at the end when she spoke about "the others who want out"? does she mean other programs like the girl, or humans in the matrix? what was her goal all along, and was she playing a game with the architect? did she want the matrix to turn into a retreat instead of a prison?
personally, as the lead developer of a large and significant (though niche) libre software project, my interest in watermarking is not to prevent illegal copying but merely to trace copying. i have thought recently about embedding serial numbers in executables. nothing would check them, providing little incentive for hackers to remove them, but they would allow me to learn who redistributed the program and on what scale. perhaps.
I love Linux, but when it comes to reliable, easy-to-install, works every time, doesn't require a degree in programming, there's something to be said about paying money for a prepackaged working solution with support and a warranty.
i'd be willing to bet you a moderate sum that this box runs linux. yamaha have already that they intend to use it on their keyboards starting within the next year or two.
Re:It?s a matter of semantics
on
Pirate Hunter
·
· Score: 1
do you have any evidence of this? not anecdotes, actual numbers to demonstrate that those who own substantial capital, earn substantial incomes and probably own significant property - that these people do not receive a disproportionate share of government spending? appeals to "aw, c'mon - they don't get welfare etc." aren't adequate to support this claim - welfare is a small fraction of government expenditure.
Slashdot Mirror
One would hope that the patent review will also ensure an in-depth audit of any alternative operating systems and applications software for issues present there. And if that can't be done, then a clear statement that it is not possible to establish the patent risk of using the alternatives.
all true. but here's my favorite story for this department. pro-audio-engineer but non-computer user buys Digital Performer and a G5. installs RME hammerfall. tries to record 8 tracks straight in from an ADAT.
there's no audio signal.
to test, user drags audio file into session. cool, region appears. test playback. no signal and no meters. no amount of anything will produce output. user switches to builtin audio. still no output.
2hrs later, after a support phone call, it is revealed that regions derived from files whose SR differs from the session will be silent. no visual indication or warning of this is ever given in the main editor window.
this is from a product judged to be one of the big 4 or 5 ... the user has had this system for nearly a year and has still never actually used it.
there is no notion of "opening" an existing file, because ardour isn't a soundfile editor. you work with sessions, which may contain hundreds or thousands or files (or just one, if you wish). so the first thing you have to do, as indicated by the big message in the editor window, is to create a new session (Session->New).
because ardour (like other DAWs) uses a track-based metaphor, you then have to create 1 or more tracks in which to place the audio you want to work with. in anything less than current CVS, Session->Add Track, then you can use the context menu for the track to embed an external soundfile. alternatively, click on the "title bar" of the region list, and use the menu to import (ie. copy and convert to native format) or embed (ie. link to and use as-is) existing audio files.
with current CVS you can simply drag-n-drop an audio file from nautilus etc. (in any format understood by libsndfile) into the editor window (the big blank area), and ardour will create appropriately configured tracks for you.
we've played with the idea of having a default session when you start up ardour. but its rather hard, because a session is a directory, not a single file, and figuring out how to handle "save" operations before the location is defined (there are several auto-save points that you can't avoid) is rather tricky.
as for what it can do that your current tools don't: if you're using soundfile editors like audacity, there is no notion of "region based" editing. ardour's editor is completely non-linear and completely non-destructive and it operates on units of informations (regions) that are assumed to have some semantic significance. metaphorically, you are laying out audio (and later MIDI and OSC) on a "canvas", not slicing and dicing the contents of a single file. it has also been my experience that most soundfile editors do not offer musical time axes, which for most "musical" editing can be deeply problematic. sequencers like rosegarden and muse obviously do, and they offer some of ardour's audio features, but a tiny subset of the set of things that ProTools users always present me with when they say "I bet Ardour doesn't dothat's ignoring all manner of other things related to its highly evolved mixer architecture and signal routing possibilities.
the manual is not the only element in the revenue strategy - i would be stupid if i believed that could ever work. but its a significant element. i've already been approached by another moderately well-known open source-related publisher about doing the manual as "a book".
the main point of me doing the manual is to give people something tangible when they pay to get ardour. sure, there might be others (c.f. craig anderton's endless list of books on cubase, sonar etc), but this is the one you can pay for and feel good about doing so :)
the full revenue model involves the manual, sponsorship, contract work, partnerships, support, donations and possibly grants.
btw, monty may be a pro engineer. but the forums for proprietary DAWs are full of comments from people who are "pro engineers" who can't figure out how to do basic stuff. this is not unique to ardour. DAWs are probably among the most complex software used by a single person, and its certainly the most complex thing i've ever been involved with (much more complex, say, than telephone switching software).
second, there is no "MS world" here - the flagship DAWs all started life on the Mac. hell, 4 years ago, PT was only certified to run on a *single* intel-based system (from IBM).
third, DAWs have all pretty much converged on the exact same feature set. you could feel that in the air at NAMM this year - nobody knows where to go next (well, the ardour project does, but it will be a while before we do). ardour attempts to get the best ideas from all of them, so although our UI is structured roughly like PT, we include the new "editor-window-mixer-strip" that originated in SX and is now in Sonar as well.
i'm not sure its worth going into this here, since monty and i have shared our fair share of flames and discussions on irc.
all i can say right now is that i don't like the fact that we have no manual, but that i have worked my ass off on this project for 4 years, and there is a limit to what i can do. and because i want to use the blender model (software: $$ free, manual: revenue source), its not really feasible for other people to write The Manual. however, i can't stop other people from writing manuals. strangely, though, from all the complaints about the opaque functionality, no such manuals have emerged. perhaps people really want me to make a living from this thing after all ...
as for "a million buttons", we have less buttons than protools and samplitude, so that can hardly be a central issue. if you don't like the colors, you can change them without recompiling, or you could pay or otherwise convince someone to do a new GTK theme (an alternative one already exists that may become the default for 1.0).
i would love to see ardour be simpler for new users to just walk in and start using. but i am more concerned that the software architecture is adequate for the extraordinary things that a DAW is expected to do. as my confidence in that grows, actually writing the manual starts to make more and more sense.
and yes, ardour's bias has been towards *recording* audio because i wrote it as a tool for use recording studios. it has slowly started to adopt more functionality when it comes to handling existing audio files, including (these days) full support for drag-n-drop direct from nautilus and similar file system browsers.
finally, we have lots of new users who stop by the #ardour IRC channel and get lots of help from everyone including pro-users, other new users, experienced users and the core developers. the majority of them get things figured out pretty quickly and then seem quite happy. not the best possible "new user" experience, but not the worst either.
sure, i'm the primary author of ardour.
audacity is a soundfile editor, ardour is a digital audio workstation. you can do some of the same things in each - record audio, chop it up, apply FX and so forth - but they are not equivalent in a deeper sense.
ardour is modelled on proaudio apps like protools, nuendo and samplitude. its not intended to be used for simple editing tasks, but for complex multi-track, multi-channel audio work. we hope that its UI will evolve to make the simple stuff simple, but our initial goal has been to make sure we have an internal architecture that can do anything the high-end proprietary apps can do, and more.
if you don't know how the high-end tools work, ardour will seem very very complex (and the current lack of a manual won't help much with that). if you have used protools, ardour will seem relatively familiar to you, although we attempt to take best-of-breed features from all the other DAWs. otoh, DAWs have all pretty converged on the same core feature set, so the differences have more to do with GUI nuances than functionality.
there is no POSIX call to wait on a mutex *AND* a change in the state of a file descriptor. you can't wait on different kinds of events at all (semaphores, file descriptors, mutexes, signals). its bad.
can anyone name any patents in the domains that intrigue most /.'ers that have actually been invalidated because of prior art? any? even one?
jmusic has nothing on the facilities offered by the programs mentioned in the parent. PD is an incredible environment for experimental music composition.
Too bad those laws didn't stop Ronald Reagan from accepting some kind of peerage from her majesty, eh?
No, if you want an analogy in the audio domain, SVG is closer to MPEG4-SA (Structured Audio). It contains both instructions on how to make the sounds, and on when to make them. SAOL is the most well-formed implementation of MPEG4-SA so far.
I am JACK's primary author. I hope I can explain some of the basics to you.
1. What the hell is a signal graph (re: your response above)? Of what I've read about JACK, that's the first time I've seen that expression? Or by "signal graph" do you simply mean "a graphical environment for stringing together a sequence of signal processing modules into an overall application"?
When audio programmers talk about a signal graph, they are using the term to refer to a rather abstract conceptualization of what is happening in software (sometimes in hardware). The model is of a series of "nodes" each of which processes a signal in some way. Each node is connected to one or more other nodes, for input and/or output. You can build a very simple graph, such as some kind of node that reads from a disk file and sends output to another node that delivers it to an audio interface. Or you can build incredibly complex graphs in which the signal is routed all over the place, possibly even including through feedback loops.
JACK is merely one of many systems that use the model of a signal graph internally; GStreamer is another.
2. You say that JACK is for communications between different processes. My understanding was that JACK was for communication between different sources/sinks of audio signal. Those could be processes, but they could also be hardware devices. For instance, when I start jackd prior to running rosegarden4, I tell it to use the ALSA driver for output. In fact, I thought that it could really be anything that could provide or accept an audio signal (even files, network URLs, etc.), since some sort of "virtual device" could be specified for them. Is that not correct? And if it is correct, how is that different from Gstreamer then?
Gstreamer is really a toolbox to be used by a SINGLE program to construct processing pathways (aka "signal graphs"). It offers no facilities (other than connections to JACK) that allow MULTIPLE processes to route data among themselves.
As to what a JACK client does with the data it receives - that is entirely up to the client. We have some clients that stream to an icecast server, other people are working on UDP and RTP-based networking, others write data to disk etc. But JACK knows nothing about this, its entirely internally to each JACK client.
3. What do you mean by "with Gstreamer the whole graph is in-process"? Are you saying that you use the graphical signal path editor to create an application out of modules, but when you're done it links (in the post-compilation sense) the modules together into a single executable which has the capability described by the network? Because otherwise -- if the modules do their work independently and pass data between each other -- that sounds like processes talking to processes, just like with JACK. What am I missing?
As I mentioned above, Gstreamer is used by a SINGLE application to build processing pathways. It is of no use whatsoever in building multiprocess pathways, other than its connection to JACK.
4. My understanding of the whole point of JACK is that it's for low-latency audio work. But it sits between processes, or between devices and processes, or whatever; how can that be lower-latency than if JACK wasn't there at all. For example, rosegarden4 uses JACK to pass data to the ALSA driver for my soundcard. How can that be lower-latency than if rosegarden4 just talked to the ALSA driver directly?
For a situation involving only one process (such as rosegarden), its certainly possible for direct access to provide marginally lower latencies than with JACK. But when I say "marginal", I really mean it. On a modern CPU, and with the right kernel, you can basically JACK as low as your audio interface can handle. The reason that JACK's design matters for latency is 2-fold. First of all, it imposes the correct model of int
does anybody believe that the "SMP" used in reference to the French Telecom DB means "symbol manipulation program" rather than "symmetric multiprocessing"? how are we supposed to take seriously a study (or at least a report about the study) where they just look up acronyms with no understanding?
"in almost every benchmark" ... sure. problem is, it doesn't beat it in the benchmarks that matter for pro-audio.
because most pro-audio apps use floating point as the basic representation of audio samples, and the athlon wipes the floor in terms of FP performance.
intel chips not only have worse FP performance, they have an unbelievably bad problem with denormals that can cause code to slow down by factors of 4-100.
cubase sx has already been ported to linux. steinberg see no market for it. keep in mind that neundo (which is where the technology inside sx originates) was first written for irix ...
% killall mozilla
or
% killall mozilla-bin
ymmv. mozilla has never hung on me since about 1.0.3
why do you think it was the machine god that defeated smith? why not the idea that neo needed smith to "take over" himself so that he could (neo) could take control of smith, analogous to what neo did in the first movie. by the time smith sees the error of his move, its too late. the machine god didn't disagree with neo when neo said "you cannot stop him, but i can". neo is the only one with the power to stop smith, but smith has to do his "takeover" first ...
the architect did not say that. the oracle asked him if the others who wanted out would be released. she never said humans. she could just as easily have meant other programs in the same situation as kadya.
my current answers:
smith was a threat because he had found a way to get out of the matrix in the real world. if he could take over humans, he could certainly take over machines.
still, its weak. one would think that taking over machines would be easier for the machines to prevent.
neo had to allow smith to "take him over" before he could exert ultimate control and destroy neo. smith had to get "inside" neo before neo could exercise his ultimate choice. so to speak.
MAJOR SPOILERS MAJOR SPOILERS MAJOR SPOILERS
since MFN is crushed by the load ...
i did tell you about the MAJOR SPOILERS, right?
anybody have any thoughts on who the oracle was referring to at the end when she spoke about "the others who want out"? does she mean other programs like the girl, or humans in the matrix? what was her goal all along, and was she playing a game with the architect? did she want the matrix to turn into a retreat instead of a prison?
personally, as the lead developer of a large and significant (though niche) libre software project, my interest in watermarking is not to prevent illegal copying but merely to trace copying. i have thought recently about embedding serial numbers in executables. nothing would check them, providing little incentive for hackers to remove them, but they would allow me to learn who redistributed the program and on what scale. perhaps.
i'd be willing to bet you a moderate sum that this box runs linux. yamaha have already that they intend to use it on their keyboards starting within the next year or two.
do you have any evidence of this? not anecdotes, actual numbers to demonstrate that those who own substantial capital, earn substantial incomes and probably own significant property - that these people do not receive a disproportionate share of government spending? appeals to "aw, c'mon - they don't get welfare etc." aren't adequate to support this claim - welfare is a small fraction of government expenditure.