Flywheel


What are the specs that X1 was running on if i may be so bold?

Also do you think that systems specs should measure up before purchase (I am being serious here)

I have thought about this for a while if they were specifications on details and models I think it would make for a better experience. I am wondering whether Cakewalk have a valid opinion on it?

NAMM main stage was an HP Z800 workstation. Dual Xeon 6 core with 12gb RAM and RAID 0 Velociraptors drives.


My personal system is a PC Audio Labs i7 3.2ghz with 12gb RAM and Intel SSD drives.

Thats a hefty system you guys had a NAMM.. 12 cores so you were probably pumping out 24 cores total. I too am using 2 Xeons, 12 cores (24 total). What kind of audio card you using?

Scott Lee

Thats a hefty system you guys had a NAMM.. 12 cores so you were probably pumping out 24 cores total. I too am using 2 Xeons, 12 cores (24 total). What kind of audio card you using?

Yup exactly. We were using an Octa-Capture with 1.5 drivers.

yorolpal

John T


In the interests of balance: I couldn't care less about gapless audio. I can understand its value if you were trying to do live performance, but outside of that, it's just a nicety really. I think this is illustrated by the argument for it's inclusion being "other DAWs do it" rather than "it's useful to me in this way". Don't get me wrong, it would be pleasant and all, but it's not actually *useful* as far as I can see.

Well, I think you're wrong on both counts JT, ol pal.  First as to your "only real value being live performance" argument I can tell you that being able to adjust any parameter or pop up any soft synth or effect and then tweak their settings on the fly is not some silly superfulous fluff.  It dramatically improves both your workflow and your confidence in the program you're running when simply recording as well.  Which leads me to my second argument for "gapless audio".  If your DAW is the least bit prone to crashing (as several of Sonar's iterations have been for many users) then ANY stutter, pause, glitch during operations is cause for consternation...if not downright fear and stress.  I can tell you that, dimbulb that I am...knowing better but still forgetting to save as often as I should...that those seeming "freezes" when performing a mundane task without first stopping Sonar's playback have caused certain parts of my anatomy to pucker and my heart to skip a beat when running Sonar at capacity.  I still say that anyone who HAS worked with a DAW that is "gapless" and grown accustomed to it not only will be disappointed to return to one that isn't but will view it as sub-standard as well.  Try it yourself for awhile and see what you think.
 

Well put ol' pal! 


Making changes on the fly allows us composers to think less of the technical hurdles of composing with a DAW, but to focus more on the music and creative ideas. Nothing more of a buzz kill then hearing pops, crackles and clicks, thinking at any moment your software is about to tank. 


I've used this analogy before but Ill say it again. If you car has a hard start, or engine is struggling on idle, you confidence about the reliability of the car dwindles dramatically. It may still get you from point A) to B), though a nail biting experience.  

wow..this is really taking off eh?

I think it'd be great to have an engine that just wouldn't stop or glitch no matter what but TBH it isn't high on my agenda list.

There isn't much that it glitches for now anyway. Since my system upgrade even dragging the loop points backwards through the now time won't cause a drop out. Of course when I do that there is a pause but then unless the software is psychic and knows where I'm going to put the start of the loop it's got to wait for me to put it somewhere. Going forwards is no trouble at all.

One thing that has started now though is a small almost inaudible crackle/pop when I switch screensets. That never happened on my old system.

In my experience there is quite a lot of settings tweaking to do to get to that point though but at least it is a one time thing.

Turning on "always open all devices" makes my system worse not better. My timing device has always been a usually redundant in/out.

If it's as bad as some are making out, I'd have a look at some of the settings esp. audio and playback/recording I/O buffers.

Scott Lee

Thats a hefty system you guys had a NAMM.. 12 cores so you were probably pumping out 24 cores total. I too am using 2 Xeons, 12 cores (24 total). What kind of audio card you using?

And you don't use 32bit OS on that , right.
 
A s far as I know, you use MAC OSX and that has been x64bit only for over 10years time.
If you use Windows you use today Windows 7 x64bit even though there are an 32bit Windows 7-version too.
Have you seen DELL or HP sending out their computer with Windows 7 x32bit installed lately? No, there you go!
 
32 bit has no benefits, its slow, outdated, RAM limit and useless comparing to 64bit calculation.
Windows 7 is the last OS from Microsoft that even will support an own x32bit version. Windows 8 will only be released in 64bit OS.

Now although this is not a gapless audio issue I would call it glitchless. And this is the ability to switch tracks on the fly while recording midi data onto virtual or external midi instrument tracks while looping say over 4 or 8 bars. All without stopping. Using only Up/Down arrows to switch and land on any track, going in and out of record, playing parts etc. For some reason Sonar cannot do this either. (8.5 anyway not sure about X1, but I suspect not)

Hi Jeff, as you know from a previous thread I can definitely do that here in X1 with no glitching or stopping but I do get some very strange behaviour with the sounds on playback. i.e. Bass track playing back piano part while recording, although perfectly okay on playback so no it's not very intuitive for creating but nothing to do with drop outs or glitches, just MIDI routing.

IIRC I haven't tried it since X1b though so maybe c fixed it. If I get time later I'll give it another whirl and report back here.

Freddie H

Scott Lee

Thats a hefty system you guys had a NAMM.. 12 cores so you were probably pumping out 24 cores total. I too am using 2 Xeons, 12 cores (24 total). What kind of audio card you using?

And you don't use 32bit OS on that , right.
 
A s far as I know, you use MAC OSX and that has been x64bit only for over 10years time.
If you use Windows you use today Windows 7 x64bit even though there are an 32bit Windows 7-version too.
Have you seen DELL or HP sending out their computer with Windows 7 x32bit installed lately? No, there you go!
 
32 bit has no benefits, its slow, outdated, RAM limit and useless comparing to 64bit calculation.
Windows 7 is the last OS from Microsoft that even will support an own x32bit version. Windows 8 will only be released in 64bit OS.

Freddie,


One should never assume :) 


First, my experience with Cakewalk dates back to DOS Cakewalk, Pro Audio, then Sonar since its debut release. During the span of the last 20 years or so I have used both 32-bit and 64-bit PCs both at my work and home use (motion picture industry sound designer, video game song composer, recording sessions, etc). I was a avid amiga, atari ST composer during the 80s which prompted me to get heavily involved with midi based sequencing (Started with trackers pre midi with soundtracker by Karsten Obarski back in the early 80s). Once moving to the PC I found an interest (well forced interest lol) diving into tech, becoming A+ certified and grabbing my Microsoft certification. Worked as apart of the technical research group at Packard Bell, then moving on to engineering at a few other known pc tech companies.


Second, the Mac G5 was the first powerPC 64-bit desktop back in 2003, OSX 10.6 was the first OS to take full advantage it, so having a true 64-bit mac for 10 years isn't possible. Since the G5's were PowerPC based not intel, running Sonar on a "64-bit mac" was also not possible due to a completely different architecture.  (running Sonar in 64-Bit mode was not even a possibly for a PC machine ten years ago honestly. While Windows xp 64-bit was released back in 2002, very little had support for it. Cakewalk, audio driver companies, 3rd party vendors, vsts,  DX, DXI plugins did not supported the technology and took years to develop for it. THis is still why we see some plugins not accessible in 64-bit mode, 0 legacy support) 


Beside having my Mac Pro, are two audio PC workstations that have been faithful Sonar machines for the last 3 years or so. So I have a grand total of 4 machines both 64-bit and 32 bit at home (64-bit at the video game company I am currently working for as well). running both Windows 7 and XP SP3. 


Below is a pic of my studio. 2 pcs under the desk just past the floor petals and laptop.








Best,

I must have made an awful lot of useless recordings.......

I've been completely x64 bit since about V7 and I'm untalented. Is that scientific evidence?

Scott Lee

Freddie H 

Scott Lee 


Oh come now, not another go 64 bit and everything will be perfect thread. That was snuffed out countless times, lets not start that up please. 

64-bit shares the same gapless problems as the 32-bit family.   

Yes, but overall it is huge difference 32bit VS 64bit in how the computer and programs perform.  
That's how the way it is without going deeper technically. 

32 bit has no benefits, its slow, outdated, RAM limit and useless comparing to 64bit calculation. 

Useless? Thats a bold statement Freddie. Can you share with us any evidence that what you call "outdated" 32-bit ram limits sonar calculations, introducing gaping audio? I have both 32-bit and 64-bit systems that say otherwise.

Very intrigued, please post your data and findings. Thanks!

Once moving to the PC I found an interest (well forced interest lol) diving into tech, becoming A+ certified and grabbing my Microsoft certification. Worked as apart of the technical research group at Packard Bell, then moving on to engineering at a few other known pc tech companies.
 
 
Hi my friend!

 
If you are so technically competent educated as you say you are you should know exactly what I'm talking about.
Any 64 bit calculation are more than 2x times faster for the computer to calculate the x32bit string.
 
www.cs.berkeley.edu/~vazirani/.../chap1.pdf
 
All general-purpose registers (GPRs) are expanded from 32 bits to 64 bits, and all arithmetic and logical operations, memory-to-register and register-to-memory operations, etc., can now operate directly on 64-bit integers. Pushes and pops on the stack are always in 8-byte strides, and pointers are 8 bytes wide.
Also all memories and cpus are general design to work in x64bit, has been for years. 
 
Larger physical address space: The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (2⁴⁰ bytes) of RAM.[1](p24) Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses[9] and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future[1](p24)[10] (limited by the page table entry format);[1](p131) this would allow addressing of up to 4 PB of RAM. For comparison, 32-bit x86 processors are limited to 64 GB of RAM in Physical Address Extension (PAE) mode,[11] or 4 GB of RAM without PAE mode.[1](p4)
 
 
 
The architecture's intended primary mode of operation; it is a combination of the processor's native 64-bit mode and a combined 32-bit and 16-bit compatibility mode. It is used by 64-bit operating systems. Under a 64-bit operating system, 64-bit programs run under 64-bit mode, and 32-bit and 16-bit protected mode applications (that do not need to use either real mode or virtual 8086 mode in order to execute at any time) run under compatibility mode. Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software.
Since the basic instruction set is the same, there is almost no performance penalty for executing protected mode x86 code. This is unlike Intel's IA-64, where differences in the underlying ISA means that running 32-bit code must be done either in emulation of x86 (making the process slower) or with a dedicated x86 core. However, on the x86-64 platform, many x86 applications could benefit from a 64-bit recompile, due to the additional registers in 64-bit code and guaranteed SSE2-based FPU support, which a compiler can use for optimization. However, applications that regularly handle integers wider than 32 bits, such as cryptographic algorithms, will need a rewrite of the code handling the huge integers in order to take advantage of the 64-bit registers.
 
 
 
Example: Take two identical computer setup, one with Windows 7 x32 OS (or XP32 even slower) and another with Windows 7 x64.
BOOT the both in the same time. Lets see that boot fastes? Answer= Yes the x64 system.
Now start a program in the same time on both SYSTEMs. What program start fastes? Answer= Yes the x64bit program.
Now try to calculate anything, render, open extract zip-library, Search and find DATA- in Library.Who does it fastes and has completed everything more then 100 % faster! Answer= Yes the x64bit system and programs. 
  
Just talk about the RAM benefits. You can also use more RAM that improve my overall stability and usage in my computer! The WINNER = x64bit technology alone...

 
There are even more benefits that prove my statements. Yes x32bit technology is "Gameover"-today but was very useful in the past.  
  
  
  
http://en.wikipedia.org/wiki/X86-64 
 

Jeff Evans


For some the creative process is incredibly delicate and can be likened to a very thin piece of cotton, easily broken. So even the slightest interruption can seem like a major blow. So for those people the gapless audio issue is very real and noticeable

It's drifting into another  topic entirely this, but I don't really believe that. I think people who are that easlly knocked off  their stride don't actually have a stride. Certainly, I  try very  hard to avoid working with people with such a precious, unproductive attitude. 

Most here are not under pressure to compose and produce music in a short amount of time but for those who do this is a real advantage. 

I do. Almost all my work  is to very tight deadlines.These kinds of appeals to more authority than one person can claim don't really help  the discussion, I don't think. 

Gotta agree with JT's sentiments above regarding someone's "gauzy, tenous creative process".  Pfft.  No matter what your technical problems...if you are working with both budgetary and time constraints as those of us who earn our living do...you find a workaround and get it done.  And if any given piece of software won't work for you...then find one that will.  But I also agree that pulling "pro" rank on anyone won't get you very far in these discussions.  We (at least I am) are simply talking about a feature that some of us think Sonar either lacks or scores very poorly in.  Not the program in total.  The Colonel says he can insert synths, tweak away, change things on the fly with no problems.  I can too...for SOME things.  But with, for instance, UAD and WAVES...to name two...I have never been reliably able to instantiate during playback.  In fact in certain iterations of Sonar I would reliably get a crash by trying.  Now lately ol X1Expanded has been pretty darn stable for me so, in fairness, I think when I get some time away from my current project I'll do some testing with this issue and see just how truly "gapless" it is these days.  Until then though I'm gonna stop playback before instantiating most plugs or doing most destructive editing.  Again...YMMV.

Oh even silk isn't smooth enough for me...it's got to be as smooth as a baby's behind or I'm liable to just go all to pieces and have a hissy fit.