Jump to content

Interested In Moving From Sonar


Paul Russell
 Share

Recommended Posts

Hi all

I'm thinking about crossgrading from SONAR 8.0.2 to Samplitude Pro, but I have a few questions that I hope someone can shed some light on.

First, my rig, which is self-assembled:

Dual Xeon 2GHz, 16GB RAM, 4x1TB SATA drives, RME Multiface PCIe, Vista x64 SP1. I do mainly original music composition and production, some mix services, and light mastering duties.

Now, the questions:

1) What is Magix's strategy towards 64bit computing? Right now I'm using SONAr in 64bit mode as it's the only way I can load up my massive EWQL samples running on Play 64. If Magix has a 64bit strategy and a reasonable timeframe, then this would be my first consideration.

2) If there is a 64bit version coming, will it have a 'Bitbridge' style app that will still allow me to play my 32bit VSTs in the 64bit environment?

3) 64bit floating point audio summing. I already know that the Samp engine is very clean and transparent, but is there going to be a 64bit precision switch in the future?

4) Any support for Dxi at all, either in 32 or 64bit?

5) Any crossgrade offers? ;)

Thanks in advance for your help

Paul Russell

www.calamitystudio.com

Link to comment
Share on other sites

If DXi refers to Direct X instruments (since some people intermix this with other DX terminology), then yes, Samplitude handles Direct X instruments.

Best if you just try it on the demo.

Greg

Link to comment
Share on other sites

Don't discount the pain in the ass it is to go from a platform you know well, to one you don't know from at all. I was pretty good in Sonar and moved to Samp because of some issues I had with Sonar and the things I liked about Samp (stability, sound, etc).

It really sucks not knowing how to do basic things. The manual sucks. This place is pretty good but you don't get answers immidiately(Sonar forum is much more heavily traffic'ed).

I really like Samp, but feeling like a dip shit and having to figure out basic functions is a real pain in the ass.

I'm glad I switched but it is something to consider.

Link to comment
Share on other sites

Don't discount the pain in the ass it is to go from a platform you know well, to one you don't know from at all. I was pretty good in Sonar and moved to Samp because of some issues I had with Sonar and the things I liked about Samp (stability, sound, etc).

It really sucks not knowing how to do basic things. The manual sucks. This place is pretty good but you don't get answers immidiately(Sonar forum is much more heavily traffic'ed).

I really like Samp, but feeling like a dip shit and having to figure out basic functions is a real pain in the ass.

I'm glad I switched but it is something to consider.

The main thing for me early on was to remember that there are about 3 ways to get where you want to go, since the menu-driven people need to be satisfied, and the mouse-driven (right-click) people need to be satisfied, and the hotkey people (like me) need to be satisfied, etc. - so the GUI at first glance doesn't seem intuitive enough because it's 'non-static' like some other hosts, where there's at most a couple ways to get things done.

The object paradigm grew on me right away though (going back almost 11 years now :blink: ).

Greg

Link to comment
Share on other sites

It really sucks not knowing how to do basic things.

What sort of basic things do you mean Reddog ?

Well, I've been trying to figure out how to burn a 30 second clip of 6 seperate drum tracks to a cd for about 2 weeks now. The question is a basic one. It's not covered in the horrible manual, it's not covered in your very good tutorials (which are unbelievable and have helped me and this entire community immensely) and it seems like such a simple question that not many are interested in spelling out the process.

I'm not saying that Samp is horrible to learn and you should stay away. All I'm saying is that when changing platforms, you should take into consideration the time it takes to learn it. It's an uncomfortable process and you always feel stupid and like you're bothering people.

Link to comment
Share on other sites

I just read your old thread:

http://support.magix.net/boards/samplitude...showtopic=18834

I am not sure wether I fully understand the problem, but it seems to be about very basic things. As CD-burning is quite straightforward in Samp, I'm not really sure wether you will find the following helpful:

You can burn directly from a VIP, just set trackmarkers and an endmarker (if you need the latter one).

The cleanest workflow probably is to bounce stereo WAVs from you mix VIP and to load these WAVs into a new CD VIP.

I'm sure Kraznet's video tutorials cover somhow these topics, did you find them on samplitude.com?

Regards,

Ulrich

Link to comment
Share on other sites

does anyone know the answers to my original questions?

TIA

I already answered as many as I could. The rest are up to Magix (re: 64-bit, etc.) to answer.

re: burning CD's - it's very easy if you use the CD burn sequence - since it's practically a wizard that walks you through the process.

Greg

Link to comment
Share on other sites

Hi Paul,

for what V10 is worth, there's not going to be any 64 bit version. That's what you have got. Everything else is everything else.

I personally doubt that we will see any native 64 bit release within the next 12 months. As with other manufacturers, it will start with a test. I am pretty sure though that Samdev is working on 64 bit and that they are much further down the road that I am aware of.

Regards,

Sebastian

Link to comment
Share on other sites

I'd be surprised if they announce any 64-bit strategy at NAMM - but I'll be there, and will poke and prod those guys to see if they cough up any information re: V11 developments.

In the meantime - just grab the DLV version and jump in with V10, and if you decide to go for V10.2, then it'd probably be cheaper to crossgrade later on as well.

Greg

Link to comment
Share on other sites

Hi guys, thanks for responding.

Right now I think I'll wait. I've been running x64 for a year and to go back to the restrictions of 2GB of RAM would be a complete PITA, even without the investment in learning another DAW workflow.

When Samplitude announce 64bit then I'll review.

Until then, cheers and sayonara.

Link to comment
Share on other sites

Hi guys, thanks for responding.

Right now I think I'll wait. I've been running x64 for a year and to go back to the restrictions of 2GB of RAM would be a complete PITA, even without the investment in learning another DAW workflow.

When Samplitude announce 64bit then I'll review.

Until then, cheers and sayonara.

OK, thanks for checking in.

Greg

p.s Samplitude runs at 4gig, and it's audio engine is effectively already at 80bit, so....

IMO, 64-bit is still hype until plugins and media can handle it. The big ROM/Samplers out there need it in order to handle streaming overhead, but beyond that it's moot.

The Sonars and Nuendo's of the world NEED this overhead to handle the beasts that Samplitude already can.

Nevertheless, good luck out there :blink:

Link to comment
Share on other sites

p.s Samplitude runs at 4gig, and it's audio engine is effectively already at 80bit, so....

Ah, so that's why it sounds so good. :blink:

IMO, 64-bit is still hype until plugins and media can handle it. The big ROM/Samplers out there need it in order to handle streaming overhead, but beyond that it's moot.

Nonetheless, I run EWQL Pianos, Symphony Orchestra and other stuff in Play x64 and can easily exceed 10GB of RAM usage on a single project. It would be almost impossible for me to go down to an x32 app again.

Ok, well, maybe see you next year :-) Thanks again.

Link to comment
Share on other sites

p.s Samplitude runs at 4gig, and it's audio engine is effectively already at 80bit, so....

Please don't mix up 64bit for *memory access* with n bits for *signal processing*. Apparently clever marketing words out there are leading to quite some confusion... so here we go:

In most hosts (Sam/Sequoia included) audio data is processed using the <float> data type for streaming/processing audio, which means 32bits resolution. Floating here means, you get the precision where you need it within the available range, similar to a pocket calculator where the comma moves accordingly.

Float can be considered 'common ground' when it comes to communication with an audio software, such as internal DSP data streams for buffers.

Many DSP algorithms are fine with 32bits resolution. A few might need 64bits (by using the data type <double>), such as recursive structures like delays or IIR filters; otherwise rounding error accumulate pretty fast and so quantization noise increases.

80 bits resolution refers to the internal number representation of the FPU (e.g. IEEE standard), which means float & double both get expanded to the 80bits range. However, when calculations are done, numbers are stored back to the internal registers as either float or double, hence they get truncated.

Surely a developer can work with 64bits all the time, but that means you cut the internal register storage in half and double the entire data stream. FPU-internal registers are fast, but any read & write access from outside and back takes valuable processing time. So one always has to outweigh things.

Even when an algorithm calculates in 64bits precision, it is often more than OK to convert it to 32bits afterwards, as soon as any recursion is done. For instance, this is the case for a plugin when it hands back its buffer back to the host.

64bits as uses in the latest claims by other manufacturers mainly affects the memory managements, which is a different story. 64bits here means you get rid of the old 2GB limit, which is important for large projects and especially sampler usage. Perhaps Volker can add more info here what we've done within the program to cope with that. He knows best.

Link to comment
Share on other sites

Hi Sacha

Thanks for your response. I'm aware of the difference between FPU calcuations and 64 bit operating systems. I'd like a 64bit app so that I can fill my RAM full of high quality samples, and I'd like a minimum of 64bit FPU calculations (SONAR's maximum dynamic fidelity) for sound quality.

Cheers

FPU's aside, the Sonar guys have to go to their 64-bit approach, since they are using a different technique than Samplitude's current structure. At least that's my understanding.

Stupid sampler companies got us 'over a rock' with their 'high-quality samples' - what are they sampling at 96/192? :blink:

...and if the destination is still i-pods, CD's or DVD's, then all that overhead gets lost anyways, so IMO until everyone is listening to high-res surround on blue-ray (or whatever), then the Sonar guys may have jumped the gun :P

Anyways, from what I've read - Kraznet and others are already running Samp. on 64-bit OS - so that's a start.

Greg

Link to comment
Share on other sites

Hi Sacha

Thanks for your response. I'm aware of the difference between FPU calcuations and 64 bit operating systems. I'd like a 64bit app so that I can fill my RAM full of high quality samples, and I'd like a minimum of 64bit FPU calculations (SONAR's maximum dynamic fidelity) for sound quality.

Cheers

FPU's aside, the Sonar guys have to go to their 64-bit approach, since they are using a different technique than Samplitude's current structure. At least that's my understanding.

Stupid sampler companies got us 'over a rock' with their 'high-quality samples' - what are they sampling at 96/192? :blink:

...and if the destination is still i-pods, CD's or DVD's, then all that overhead gets lost anyways, so IMO until everyone is listening to high-res surround on blue-ray (or whatever), then the Sonar guys may have jumped the gun :P

Anyways, from what I've read - Kraznet and others are already running Samp. on 64-bit OS - so that's a start.

Greg

Internal 64-bit FPU calculations is one of the features I like about Sonar. Granted I don't know all the intricate details of digital audio mathematics, if one is given the option of reducing truncation errors through higher bit calculations then there is really, IMO, no reason not to go that route, regardless of the medium your product ends up as. Now whether 32-bit vs 64-bit makes any actual difference to human ears is debatable, but from a purely theoretical standpoint, I can understand where Paul is coming from.

Personally, I can forgo 64-bit accuracy if Samplitude will resolve some of the other critical issues I have with Sonar.

Regards,

DB

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...