yes, at least they did. the euclids at kemess in canada literally failed to boot, at least once in my personal experience, costing at least a day total downtime, in this specific case as a result of a failed microsoft office upgrade. sometimes the parts do matter - in this case the trucks refused to run because they were unable to offload, and thus reset, the daily logs, after having been shut down for the night. this happened, as far as memory serves, because an automatic microsoft update broke the outdated truck operating system's connection to the site's servers.
understood, however, given the half-life of facts, in general, i still feel more comfortable with a living debate, than with published results... if you take a longitudinal look back through the reputable published sources, what percentage would be considered garbage, today? for instance, how many pro tobacco articles can you find, if you go back far enough? take a look at prepupilectomy, tonsilectomy, appendectomy, etc...
as long as it takes money to publish, we will only ever get what is considerered profitable - this is not entirely a bad thing, but it is heavily limited, by design.
as an open source fanatic, i am certain that all we need to do is open source all academic work, and the results would almost instantly become as reliable as linux and as useful as gnu.
a lot of people would suddenly have to look for real work, though.
i think you're splitting hairs - i have no problem with being a half a sample behind the output (or a quarter, in a two channel i/o context) - it's being within a few tens of samples, or even a few hundred, that bothers me, especially when this is considered "good enough" for the bulk of us.
if the chips are interleaving anyway, i cannot see why it would be a problem to sync the data, since multiplexing implies a perfect integral n to n relationship in the first place, and can be demonstrated to remain in lockstep over many days, in tests i have run on multiple hardware, over the past decade. once you have the actual offset calculated, it remains stable essentially forever, or at least until your machine drops a buffer, even on the cheapest hardware.
i'm not an audiophile, but i can assure you the disorientation i experience when multi-tracking my own singing voice in a loop across a stereo pan, relying on the driver's timestamp, is very real, and that this "artifact" disappears when the data is correctly offset, using the brute force method i described above.
i'm of the opinion this problem is damaging us, as a species. in the old analog days latency was considered a big issue, now we seem to be growing a whole generation of singers who don't know what they're missing. it's not that important with an instrument, as every instrument has it's own latency, and as musicians we learn to compensate, even for the dreaded midi effect. it is when it comes to recording vocals, the difference is very obvious, and i'm concerned that very few people even realise what they're missing anymore.
hence the heavy emphasis of post processing, and the dearth of natural voice recordings, i think, and perhaps i should get off my soapbox now.
spectacular, thank you, may your offspring multiply exponetially. i think "peer reviewed" is an expression about as meaningful as an "organic" sticker. the real reviews, in my experience, happen here, and on wikipedia, etc, where i can join in. a "peerless" resource, thank you again for the pointer.
in my experience ALL pc audio hardware has been (i believe deliberately) crippled, since the late nineties. when i began writing recording software for myself, under OSS, in the previous millenium, there was a simple "set and trigger" function that allowed you to fire off the record and playback devices simultaneously, resulting in true zero latency recording. suddenly, within a very few years, this functionality began to disappear, until we arrive at the present, when it appears to be lacking completely. since, as far as i know, virtually every audio chip runs both devices off the same clock, it seems utterly ludicrous that modern multi-track, at least outside of very high end professional hardware, seems satisfied with latencies accurate to within a "few tens" of samples, as "guessed" by the driver. while this might seem a tiny offset, at 44k samples per second, it is variable, and never consistent, at least not on any "standard" hardware i have been able to test. for my own satisfaction, i have been reduced to using an external loopback, and measuring true "sync" by direct observation of the recorded output thus returned. the difference, to my ears, is stunning, especially when doubling vocals. true zero latency is very important, in any even halfway professional studio. am i missing something? as far as i can see, from fairly extensive duckducking (anti-googling, to those who care) the industry continues to ignore this most important, and essentially trivial, basic requirement. does anyone know why, or can explain what i am missing?
what happens if i don't know, if i forget, for instance, or my key store is set to autodestruct?
what happens in a distributed system like (toad's) freenet, where the keys are unknown?
and can anyone explain how this might apply in canada?
also - off topic - for pity sake, why will slashdot not recognise simple linefeeds?
the thing i like about open source is that, even when it is broken, i can "git it and fix it" all by myself, as can anyone else so inclined.
at may seem magical, but somehow the best fixes do tend to swim upstream against the current.
you lot have a broken system, and from what i am hearing, you are not expecting this to get sorted any time soon, if at all.
had it been open source this discussion would now be irrelevant, as the problems would have been fixed by now.
i believe this has been proven, over and over again, in the real world.
open source for life.
(speaking of fixing things, is anyone at slashdot interested in sorting out your apparent dependency on microsoft style cr/lf?)
Slashdot Mirror
this is no different from the theory that dropping nukes on gooks solves things.
first we should count the gooks, not forgetting us geeks on our bikes.
then we begin to calculate our energy needs.
finally we discuss who gets to drop what on whom, and why not.
cause it happens to be an emergency...
yes, at least they did. the euclids at kemess in canada literally failed to boot, at least once in my personal experience, costing at least a day total downtime, in this specific case as a result of a failed microsoft office upgrade. sometimes the parts do matter - in this case the trucks refused to run because they were unable to offload, and thus reset, the daily logs, after having been shut down for the night. this happened, as far as memory serves, because an automatic microsoft update broke the outdated truck operating system's connection to the site's servers.
it would seem we are getting there.
understood, however, given the half-life of facts, in general, i still feel more comfortable with a living debate, than with published results... if you take a longitudinal look back through the reputable published sources, what percentage would be considered garbage, today? for instance, how many pro tobacco articles can you find, if you go back far enough? take a look at prepupilectomy, tonsilectomy, appendectomy, etc...
as long as it takes money to publish, we will only ever get what is considerered profitable - this is not entirely a bad thing, but it is heavily limited, by design.
as an open source fanatic, i am certain that all we need to do is open source all academic work, and the results would almost instantly become as reliable as linux and as useful as gnu.
a lot of people would suddenly have to look for real work, though.
agree with your perspective
i think you're splitting hairs - i have no problem with being a half a sample behind the output (or a quarter, in a two channel i/o context) - it's being within a few tens of samples, or even a few hundred, that bothers me, especially when this is considered "good enough" for the bulk of us.
if the chips are interleaving anyway, i cannot see why it would be a problem to sync the data, since multiplexing implies a perfect integral n to n relationship in the first place, and can be demonstrated to remain in lockstep over many days, in tests i have run on multiple hardware, over the past decade. once you have the actual offset calculated, it remains stable essentially forever, or at least until your machine drops a buffer, even on the cheapest hardware.
i'm not an audiophile, but i can assure you the disorientation i experience when multi-tracking my own singing voice in a loop across a stereo pan, relying on the driver's timestamp, is very real, and that this "artifact" disappears when the data is correctly offset, using the brute force method i described above.
i'm of the opinion this problem is damaging us, as a species. in the old analog days latency was considered a big issue, now we seem to be growing a whole generation of singers who don't know what they're missing. it's not that important with an instrument, as every instrument has it's own latency, and as musicians we learn to compensate, even for the dreaded midi effect. it is when it comes to recording vocals, the difference is very obvious, and i'm concerned that very few people even realise what they're missing anymore.
hence the heavy emphasis of post processing, and the dearth of natural voice recordings, i think, and perhaps i should get off my soapbox now.
ouch sorry, idiot error, i failed to rtfm - thank you for taking the time.
-- Things are more like they used to be than they are now.
dammit, this would work... perhaps is working, at least subliminally... stay tuned for more.
honour != profit, q.e.d.
spectacular, thank you, may your offspring multiply exponetially. i think "peer reviewed" is an expression about as meaningful as an "organic" sticker. the real reviews, in my experience, happen here, and on wikipedia, etc, where i can join in. a "peerless" resource, thank you again for the pointer.
in my experience ALL pc audio hardware has been (i believe deliberately) crippled, since the late nineties. when i began writing recording software for myself, under OSS, in the previous millenium, there was a simple "set and trigger" function that allowed you to fire off the record and playback devices simultaneously, resulting in true zero latency recording. suddenly, within a very few years, this functionality began to disappear, until we arrive at the present, when it appears to be lacking completely. since, as far as i know, virtually every audio chip runs both devices off the same clock, it seems utterly ludicrous that modern multi-track, at least outside of very high end professional hardware, seems satisfied with latencies accurate to within a "few tens" of samples, as "guessed" by the driver. while this might seem a tiny offset, at 44k samples per second, it is variable, and never consistent, at least not on any "standard" hardware i have been able to test. for my own satisfaction, i have been reduced to using an external loopback, and measuring true "sync" by direct observation of the recorded output thus returned. the difference, to my ears, is stunning, especially when doubling vocals. true zero latency is very important, in any even halfway professional studio. am i missing something? as far as i can see, from fairly extensive duckducking (anti-googling, to those who care) the industry continues to ignore this most important, and essentially trivial, basic requirement. does anyone know why, or can explain what i am missing?
if we created the space, would academia not use it?
is it not up to us to resolve this?
if it worked for wikileaks, why would it not work here?
what happens if i don't know, if i forget, for instance, or my key store is set to autodestruct? what happens in a distributed system like (toad's) freenet, where the keys are unknown? and can anyone explain how this might apply in canada? also - off topic - for pity sake, why will slashdot not recognise simple linefeeds?
People who think they know everything are very annoying to those of us who do -- Mark Twain
just a lot of balloon juice - scrub in, aggressively monitor, and the real kicker - prioritize. they don't have a clue, do they?
the thing i like about open source is that, even when it is broken, i can "git it and fix it" all by myself, as can anyone else so inclined. at may seem magical, but somehow the best fixes do tend to swim upstream against the current. you lot have a broken system, and from what i am hearing, you are not expecting this to get sorted any time soon, if at all. had it been open source this discussion would now be irrelevant, as the problems would have been fixed by now. i believe this has been proven, over and over again, in the real world. open source for life. (speaking of fixing things, is anyone at slashdot interested in sorting out your apparent dependency on microsoft style cr/lf?)
thanks, frankly, for leading such perfect cases, in point, of the specific colour-however-you-spell-it-blind-ness in question.
bravo, sage, or however it is done, around here.