redbarchetta
guitardood
redbarchetta
@guitardude
Correct me if I'm wrong but isn't part of the alure of 64 bit vs 32 bit the ability to move more data more quickly. Like for fetch operations and what not?
I'm a software developer myself but not a bit twiddler. As said, I didn't like my assembly classes. Closest I'd ever want to go there again is "C"
I'm sure that's part of it, though with all the caching being done on-die I think the real significant reason for 64-bit is the ability to access more in-memory data. IMHO, in a streaming app such as Sonar, you could have a 256-bit CPU/OS/Compiler and it will still stream at whatever speed the disks could provide data. It's a bit different for the sampling soft-synths which utilize large memory buffers (BFD,Kontakt,Machfive, et al) to load as many samples in ram as possible, primarily to cut down on latency.
Best,
How much memory can Sonar utilize? Also, have you ran sonar with a SSD? Wondering what kind of performance enhancements you'd get with one of those.
While technically Sonar could use every bit of RAM you throw at it, I have a feeling that Sonar's actually memory footprint is quite small (less than 1gb) even with a lot of non-synth FX. In my experience, the only thing that really starts Sonar's memory usage to climb is loading a large memory-footprint plugin like BFD/BFD2. Bear in mind that I haven't seen even 1 line of source code from sonar and I'm making a lot of conjecture as to it's operation based solely on my experience running it.
I haven't any experience with SSD drives, but the last time I thought about purchasing one (over 6 months ago), I couldn't justify the cost for the marginal increase in "rated" access times.
Best,