The Samplitude Sounds Great Thread

[Aloysius]

These cables sound great.

[sascha]

What I mean by this is people who haven't entirely lost the ability to hear up near the nyquist, but have reduced differential capabilities in this area of the frequency spectrum, may find that the hiss is more prominent when a filter cuttoff is walling against the decay of those sounds? Thus giving them an impression that Samplitude sounds better/clearer/more pristine.

That's a bold statement, and you should be very cautious since you have no idea who is all reading this...

That ridiculous theory would only be true if you're making music that only elderly people listen to, right? Funny. Nah, rather not.
Let me think... by the time I was in their dev team we had good contact to many LA-based studios, but also on the other side of the US, Sterling Sound NY. Check your music collection for some of their masters, chances are many were made with Sequoia.
And that's only one of the many references I could bring. But much actually happens in Classical, Jazz and broadcast. But... hang on, that's elderly people... ugh...

From my many years working on the other end I can assure there is no secret sauce of automatic up/down/whatever sampling involved unless you clearly specify it (like dithering or realtime resampling when you have souces in your project that are of different sample-rate origin). Everything is just 'correct' maths, although the core team has made huge effort in the engine part to keep any truncation and rounding errors out of the equations as much as possible, which gets harder with high-track count. It actually matters where and when you sum up, and showing any single ASIO glitch as error in the info section is a rarity among DAWs, most of them leave it up to you to to figure out acoustically. The 'trick' is just that Samplitude & Sequoia don't leave you in the dark. Again, there are thousands of clients working with Sequoia in national broadcast stations, and also Federal archives and forensic labs. That application was designed to fulfill specifications that go way beyond ordinary musicians' needs. It's mainly sticking to solid engineering virtue (the core team leader is a PhD physicist, btw), and nobody has ever thought snake-oil business there. It's perhaps a mentality thing, I've rarely met people who are more down-to-earth and devoted to that thing than there.

[WotEva]

I remember reading a report on Magix a while back where the article stated that there some potential future financial concerns for Magix as more than 50% of their customer base were over 45 years of age. I personally haven't come across any particularly youthful Samplitude users. Not to say they don't exist. I have chatted to two blokes a while back who were early to mid 30's and used the platform, but most seem to be 40+.

The reason I bring this up, is hearing. Most people slowly lose the top end of their hearing as they age. As some have pointed out, Samplitude automatically upsamples.

Is it possible that the reason for the impression by some that Samplitude sounds better, is that middle aged users are perhaps hearing the results of the filter cutoff of most DAWs as a percieved fuzzier/nastier hiss? It might be the case that Samplitude's up sampling makes that top end sound slightly smoother to those who are losing hearing in that area?

What I mean by this is people who haven't entirely lost the ability to hear up near the nyquist, but have reduced differential capabilities in this area of the frequency spectrum, may find that the hiss is more prominent when a filter cuttoff is walling against the decay of those sounds? Thus giving them an impression that Samplitude sounds better/clearer/more pristine.

Nonsense.

Care to elaborate on what exactly is nonsense?

Remember we are talking about musicians who are not only ageing but have potentially been exposed to half a lifetime worth of concert/practice volume music. Of course this is not a generalisation about everyone over a certain age. The question is in regards to what I presume is but a small percentage of people. And it certainly could apply to anyone of any age that has reduced capacity in hearing range/perceptibility.

Of course we know for a fact that there are Samplitude users who do not hold the opinion of the program holding some added mystique. We also know that whilst everyone's hearing will eventually degrade, that the how, the why, the effects experienced and the variances of all potentialities will differ wildly from individual to individual.

Any input is appreciated. Do you have any medical/laboratory human hearing based facts to back up your statement that the questions posed are of a nonsensical nature, or is it just a feeling you have?

[sascha]

Of course we know for a fact that there are Samplitude users who do not hold the opinion of the program holding some added mystique.

For heaven's sake, what's up here???
I might not have been clear enough in my previous post (that you seem to have ignored). I was part of their developer team for roughly a decade, and I did numerous DSP stuff there. While some of DSP effects are actually designed to have a sonic fingerprint, the program itself - the very sequencer/audio engine - is not. The program has no 'added mystique'. Period.
The only mystique here is you trying to talk people into something. Please stop that.

[Cooker]

My Samplitude story;

Back in college (like 10-15 years ago), we had a nice studio to work/learn but it was a PT HD system and LE those days was so crippled non-mac user students like me used Cubase.

So one day I was doing this mix which needed a lot of cpu use, finished and rendered but noticed the render sounded different. Called a few friends, we checked everything and listened carefully and yeah Cubase indeed changed the sound of render (or the playbacksound , not sure which) if cpu was high. Keep in mind this was a really old version of cubase.

Obviously I needed a new DAW and after reading the "sound" of samplitude being so nice gave it a shot, basic workflow wasn't really different from Cubase either and for audio it had amazing offline options (very fast to work with)+the object editing was so interesting. The cpu thing didn't happen+it calculated latency more accurately (needed a stop/play though everytime a plug-in is inserted while audio is playing) and this increased the clarity of the mix very noticeable.

Also got interested in mastering as not many back then exactly knew what they were doing, Samplitude was more ready then I was. Even today one can make an MFIT master on pc without buying plug-ins if they have Samplitude.

[WotEva]

What I mean by this is people who haven't entirely lost the ability to hear up near the nyquist, but have reduced differential capabilities in this area of the frequency spectrum, may find that the hiss is more prominent when a filter cuttoff is walling against the decay of those sounds? Thus giving them an impression that Samplitude sounds better/clearer/more pristine.

That's a bold statement, and you should be very cautious since you have no idea who is all reading this...

That ridiculous theory would only be true if you're making music that only elderly people listen to, right? Funny. Nah, rather not.
Let me think... by the time I was in their dev team we had good contact to many LA-based studios, but also on the other side of the US, Sterling Sound NY. Check your music collection for some of their masters, chances are many were made with Sequoia.
And that's only one of the many references I could bring. But much actually happens in Classical, Jazz and broadcast. But... hang on, that's elderly people... ugh...

From my many years working on the other end I can assure there is no secret sauce of automatic up/down/whatever sampling involved unless you clearly specify it (like dithering or realtime resampling when you have souces in your project that are of different sample-rate origin). Everything is just 'correct' maths, although the core team has made huge effort in the engine part to keep any truncation and rounding errors out of the equations as much as possible, which gets harder with high-track count. It actually matters where and when you sum up, and showing any single ASIO glitch as error in the info section is a rarity among DAWs, most of them leave it up to you to to figure out acoustically. The 'trick' is just that Samplitude & Sequoia don't leave you in the dark. Again, there are thousands of clients working with Sequoia in national broadcast stations, and also Federal archives and forensic labs. That application was designed to fulfill specifications that go way beyond ordinary musicians' needs. It's mainly sticking to solid engineering virtue (the core team leader is a PhD physicist, btw), and nobody has ever thought snake-oil business there. It's perhaps a mentality thing, I've rarely met people who are more down-to-earth and devoted to that thing than there.

You say, "bold statement." I take it you did not notice the question mark, nor the question marks in the paragraphs prior to that?

Your second paragraph (re: Ridiculous theory) is a little confusing. You seem to be pointing out that old people listen to music that was mastered in Sequoia, as if that is making a point against the questions I posed. It appears to me that you may have misunderstood what I wrote.

I am also not sure what, "much happens in classical, jazz and broadcast," has to do with what I wrote? Also 45 years of age is not commonly considered "elderly." I realise that yourself and others may have taken what I posted as a sweeping generalisation. So allow me to explain that I am only talking about what I presume to be a very small percentage of people and in fairness, could apply to anyone of any age that has reduced hearing capacity/perceptibility.

You said that you were part of the dev team, do you mind me asking what your role was specifically?

[sascha]

> Also 45 years of age is not commonly considered "elderly."
For the record, I'm 47.
You don't seem to have discovered the irony I was trying to stress becaue of your posts. No matter how you turn it, it needs pointing out Samplitude/Sequoia doesn't alter the audio data in any way, unless you explicitly want it.

I was hired at Magix from 2000 to 2012. From 2003 on, I was one of the 3 DSP developers, and I indeed made some of the 'mystique' things there (if one could call them so), as my main role was circuit emulation and room acoustics. I did the Vandal guitar amp, VariVerb, the Analogue Modelling & Vintage Effects suite, essentialFX suite, Revolta & Robota synth and a couple of other smaller tools. The others in the (DSP) team remained focused on the more scientific/surgical parts (like linear-phase EQ, FFT filter, IR room sim, surround & spectral tools, metering standards, restoration & spectral cleaning etc.) and still do. The engine itself is completely decoupled from any in-depth DSP routines, it just makes sure signals arrive in time at the right spot and get summed up *correctly* to their respective buffers.

[WotEva]

Of course we know for a fact that there are Samplitude users who do not hold the opinion of the program holding some added mystique.

For heaven's sake, what's up here???
I might not have been clear enough in my previous post (that you seem to have ignored). I was part of their developer team for roughly a decade, and I did numerous DSP stuff there. While some of DSP effects are actually designed to have a sonic fingerprint, the program itself - the very sequencer/audio engine - is not. The program has no 'added mystique'. Period.
The only mystique here is you trying to talk people into something. Please stop that.

Haha I actually just replied to your post. I am in Australia so we are on opposite sides of the world. I guess I should apologise for needing to sleep and work? But I think you may have confused what I am writing and asking?

I am a sceptic to Samplitude having "a sound." I own the program and I personally do not hold this opinion.

But I have noticed that there seems to be a small contingent of sometimes very experienced users, who do believe that Samplitude has a superior sound to other offerings. As those users have failed thus far to provide audio examples and methods of testing to back this up, I am merely floating questions as to why a number of people would hold this view. I have already stated that it might be placebo effect due to marketing, but I also do not think that these people are crazy or deliberately trying to mislead.

My question about hearing degradation is just a possibility. I am not trying to talk anyone into anything. In fact I am not even sure how you could talk someone into something by simply posing questions?

Thanks for replying with regards to your role. Surely you would have come across users who believe Samplitude has a sound?

Also what do you say in response to one of the previous posts in this thread, that a Magix dev suggested that Samplitude's audio engine is the more accurate than some competitiors?

Source: Sound on Sound interview.

From the very beginning, two hallmarks have defined the philosophy behind Samplitude: [snip] and an obsessive commitment to purity of sound quality.

Herberger is sceptical about the notion that there are no sonic differences between audio programs. [snip]

I think the big thing about the sound quality is to make no mistakes. You must not do mistakes in the DSP. It's a big goal, and a lot of errors and not-clever routines are done by a lot of parties on the market, and people who are trained to hear audio will discover these immediately. Six or seven years ago, we had a patch for a new Samplitude version, and one day an American guy called us and said 'Hey, you did something wrong in your program. It sounds bad now.' We measured, and did tests, and after a long time we found out that in the 24th bit of the audio in going from floating-point arithmetic that we do internally down to the sample level through a 24-bit converter, we forgot the dithering. I personally could not hear this, to be honest — but you can measure it, and in a program as huge as Samplitude, you have a thousand points where you can make a mistake of this sort.”

I only ask because, if that claim is true, then surely there should exist some examples showcasing the inaccuracy of other platforms output in comparison to Samplitude?

[sascha]

I don't know of any showcases in this regard, maybe sometimes people do blind auditions or so, but sometimes those discussions easily stray away into the more esoteric field.
Tilman Herberger is the former CTO & board member, my ex-boss and one of the two 'fathers' of the program (and an excellent Jazz pianist btw.). He did the first versions in the late 80s together with Titus Tost, as a research project for a department of the music conservatory of the Dresden university, on a... wait for it... Commodore Amiga, that they got from Western-German relatives (which might have been quite an obstacle getting it over to Dresden as the iron curtain was still hanging in the air...). At least a couple of years ago that Amiga was still residing in a glass cabinet in Titus' office. Of course it was 16bit integer, and the first PC version was pretty much the same. It all lifted off in quality when 32bits float where implemented later on (I think it was in v5, 1996 or so), but the problem with conversion to other domains like 20 or 24bits integer remained, and that's where a lot of effort went into. Later on came more complex environments, more tracks, ASIO, realtime DSP, multicore/multithread and a thousand ways to potentially mess something up.
I think it's safe to say the devil's in the details. Modern DAWs are very complex pieces of software, apart from calculating things without truncation or causing accidental interpolation noise, they have to work in realtime, stay synced-up to externall processes or gear (often have to even out external clock jitter) and communicate extremely fast and precise to the outside world. As said earlier, it might be a key aspect to report any glitch, lost buffer or load spike. If you don't you just can't rely on the app in situations where it matters.
I'm not saying others wouldn't do their homework, I just want to stress that any DAW should have that attention to those very tiny details (that might bind quite some resources in the development but rarely pay off right away), and it might just be a gut feeling but I don't sense that very often elsewhere.

[WotEva]

My Samplitude story;

Back in college (like 10-15 years ago), we had a nice studio to work/learn but it was a PT HD system and LE those days was so crippled non-mac user students like me used Cubase.

So one day I was doing this mix which needed a lot of cpu use, finished and rendered but noticed the render sounded different. Called a few friends, we checked everything and listened carefully and yeah Cubase indeed changed the sound of render (or the playbacksound , not sure which) if cpu was high. Keep in mind this was a really old version of cubase.

Obviously I needed a new DAW and after reading the "sound" of samplitude being so nice gave it a shot, basic workflow wasn't really different from Cubase either and for audio it had amazing offline options (very fast to work with)+the object editing was so interesting. The cpu thing didn't happen+it calculated latency more accurately (needed a stop/play though everytime a plug-in is inserted while audio is playing) and this increased the clarity of the mix very noticeable.

Also got interested in mastering as not many back then exactly knew what they were doing, Samplitude was more ready then I was. Even today one can make an MFIT master on pc without buying plug-ins if they have Samplitude.

I agree that Samplitude is definitely pretty close to a one-stop shop for production. Just needs some more midi and prv tricks/stuff/functionality to tighten up the composition end of things.

I do wonder if some of this perception is merely a carry over from the days Jim spoke of?:

I don't think you'll find too many folks making that same argument (today).
Now that many DAWs are summing in 64Bit double-precision Float, the subject is pretty well moot.

Samplitude was one of the first DAW applications to support 32Bit Float files/processing.
Years ago, the Object based editing brought realtime/non-destructive control that other DAWs just didn't have.

As I am sure some would have bounced a track completed in a 64 bit host and loaded it into a 32 bit host. Only to find that the track which played back fine in its original host was now clipping, or appeared to have a playback artefacts, even when it did not display clipping when played back via a CD or thumb drive on any speaker source. The extra head room and being one of the first to the party, could be at the foot of these beliefs?

It may also explain Teddy Riley's once held belief that SO1 can be pushed further and doesn't crack?

[WotEva]

I don't know of any showcases in this regard, maybe sometimes people do blind auditions or so, but sometimes those discussions easily stray away into the more esoteric field.
Tilman Herberger is the former CTO & board member, my ex-boss and one of the two 'fathers' of the program (and an excellent Jazz pianist btw.). He did the first versions in the late 80s together with Titus Tost, as a research project for a department of the music conservatory of the Dresden university, on a... wait for it... Commodore Amiga, that they got from Western-German relatives (which might have been quite an obstacle getting it over to Dresden as the iron curtain was still hanging in the air...). At least a couple of years ago that Amiga was still residing in a glass cabinet in Titus' office. Of course it was 16bit integer, and the first PC version was pretty much the same. It all lifted off in quality when 32bits float where implemented later on (I think it was in v5, 1996 or so), but the problem with conversion to other domains like 20 or 24bits integer remained, and that's where a lot of effort went into. Later on came more complex environments, more tracks, ASIO, realtime DSP, multicore/multithread and a thousand ways to potentially mess something up.
I think it's safe to say the devil's in the details. Modern DAWs are very complex pieces of software, apart from calculating things without truncation or causing accidental interpolation noise, they have to work in realtime, stay synced-up to externall processes or gear (often have to even out external clock jitter) and communicate extremely fast and precise to the outside world. As said earlier, it might be a key aspect to report any glitch, lost buffer or load spike. If you don't you just can't rely on the app in situations where it matters.
I'm not saying others wouldn't do their homework, I just want to stress that any DAW should have that attention to those very tiny details (that might bind quite some resources in the development but rarely pay off right away), and it might just be a gut feeling but I don't sense that very often elsewhere.

Thanks for your input. I cannot imagine what it would have been like to work in digital audio back in the Amiga days. Dealing with the limits of such tiny memory capacity must have turned a few fully-haired men and women into bald ones. Although, I guess at the time they may have marvelled at what was thought of as being a huge amount of memory and relished such a time to be alive?

Did you have much interaction with competing companies during that time? I am curious to know how many trade secrets were shared between staff behind the scenes at trade shows and the like. Of course I suspect that most would have kept tight-lipped, but if you can dish some tasty insider gossip, please feel more than free to take this thread a bit off topic.

[sascha]

As I am sure some would have bounced a track completed in a 64 bit host and loaded it into a 32 bit host.

It doesn't matter if the host is 32 or 64bit. The underlying program architecture has nothing to do with the DSP part. Typically, DSP code on x86-based architecture is 32bits float, and sometimes developers switch over to double precision (64bits) when the code calls for it. For instance, in IIR filters or other feedback structures like delay lines, everywhere where errors propagate and pollute the audio over time. This is important when storing data outside the CPU/FPU, aka when it leaves internal registers or the pipeline, and IEEE standard ensures 80bit precision inside the FPU. It all becomes more complex when code isn't calculated as scalars but as vectors inside the processor, to benefit from parallel-processing speed. Some instruction sets want float, others can do double. Some compilers are smarter than others, and some developers leave it all up to the compiler while others take it in their own hands, and some think they outsmarted the compiler. A million ways to go right or wrong. But again, it's not a question of 32 or 64bit platform.

Clipping is another thing. Some people wonder where the -0.2dbFS rule-of-thumb comes from. It's a dumb rule, completely arbitrary unless you know about the Gibbs effect and how interpolation and a reconstruction filter in a DAC works. People bounce to 16bit in their DAWS and their limiters chopped-off their waveforms and then wonder why it looks clean in the waveform but sounds distorted on certain devices.

[sascha]

Did you have much interaction with competing companies during that time?

Sure. Although 'competition' is difficult in this small business field. Bigger companies try to steer it a bit for their employees, which is natural, but smaller ones don't, or it might depend on the company's culture.
There are intersections between soft- & hardware companies enlarging the pool of people, but many of us know each other, be it from ancient mailing lists, forums, trade-shows, business partnerships or former job positions. And everyone of us can tell stories where you end up in some bar with fellows from abroad that you haven't seen in a while discussing things like... DAW mystiques... over some booze in a hotel bar, and wake up with a massive hangover. The better get-togethers then ended with discussions other than DAW mystiques...
We still favour that at u-he, that's why some colleages insist on having caffe corretto or Gin ready on a trade show.

[WotEva]

As I am sure some would have bounced a track completed in a 64 bit host and loaded it into a 32 bit host.

It doesn't matter if the host is 32 or 64bit. The underlying program architecture has nothing to do with the DSP part. Typically, DSP code on x86-based architecture is 32bits float, and sometimes developers switch over to double precision (64bits) when the code calls for it. For instance, in IIR filters or other feedback structures like delay lines, everywhere where errors propagate and pollute the audio over time. This is important when storing data outside the CPU/FPU, aka when it leaves internal registers or the pipeline, and IEEE standard ensures 80bit precision inside the FPU. It all becomes more complex when code isn't calculated as scalars but as vectors inside the processor, to benefit from parallel-processing speed. Some instruction sets want float, others can do double. Some compilers are smarter than others, and some developers leave it all up to the compiler while others take it in their own hands, and some think they outsmarted the compiler. A million ways to go right or wrong. But again, it's not a question of 32 or 64bit platform.

Clipping is another thing. Some people wonder where the -0.2dbFS rule-of-thumb comes from. It's a dumb rule, completely arbitrary unless you know about the Gibbs effect and how interpolation and a reconstruction filter in a DAC works. People bounce to 16bit in their DAWS and their limiters chopped-off their waveforms and then wonder why it looks clean in the waveform but sounds distorted on certain devices.

Can you expand on?: "Some think they outsmarted the compiler"

How did you come to this conclusion in regards to competitors software?

[Cooker]

I agree that Samplitude is definitely pretty close to a one-stop shop for production. Just needs some more midi and prv tricks/stuff/functionality to tighten up the composition end of things.

I do have a Samp.+Logic user friend, leaving the midi part to Logic but he makes pretty advanced stuff that doesn't aim commercial music.

Plug-ins internally can handle a lot these days to save time for the user and I suspect not many still use advanced tricks/routing as much as they used to, meaning the DAW part's role has decreased a bit compared to the past. So just saying samp.s midi editor should handle pretty much everything going on for a typical homestudio guy.

2 concrete negative opinions I know of Samplitude is being buggy and vst/midi poor. But specially to me starting at X3 they've really taken care a big part of such complaints. Today, I don't see as much complaint on the samplitude forum compared to the past when a new version was released.