V-DAT Quality

ibz01 · Post by **ibz01** » Tue Jul 20, 2004 3:27 pm

Thank you to everybody.
Maybe if I was able to test a VDAT demo I could talk about it and maybe work with it.
But Creamware doesn't offer(?) a demo.
For me is a strong handycap that I can not reload a wav file into a track slot. The independent editing of each track is a problem too.
If I could use VDAT I would only use in the recording step.(uf, dificult english explanation)

blazesboylan · Post by **blazesboylan** » Tue Jul 20, 2004 3:27 pm

It never failed me.

Hmmmm, on second thought you're right. A few years ago I recorded rehearsals using Vegas. Vegas would crash but SFP would keep going.

If I had had VDAT back then I wouldn't have lost a few moments of inspiration!

astroman · Post by **astroman** » Tue Jul 20, 2004 5:07 pm

On 2004-07-20 16:27, ibz01 wrote:
...But Creamware doesn't offer(?) a demo.
...

there has never been a VDAT demo - that way it took me almost 2 years to understand it's true value.
I just got on the wrong trail by that (marketing) focus on Adat integration, which of course is phantastic for all Adat owners.

But it just didn't enter my mind that VDAT was the most powerful and cheap replacement for any external digital recorder.
For some time even I thought of a Fostex or something like that...

I want something which needs just a single button press to record a bunch of tracks in the right moment.
VDAT seems to be extremely resource effective and spares the transfer of files from the external recoder.
It's a no brainer to capture 20 minutes of a scenario and mark the 'best' segments to bounce them to a 'condensed' tape, which then can be arranged and edited by whatever app applies.
As Marcupocus explained it's unbeatable in live situations and renders almost any Roland, Korg etc portable studio to unemployment.
A cheapo PC in a rackmount with a Scope home and VDAT is also an extremely cost effective solution - considering routing and fx quality supplied.

But you're absolutely right: with a demo I would have bought it much earlier - shame on me, I got it for 99 Euro for the SFP4 registration...

cheers, Tom

medusa13 · Post by **medusa13** » Tue Jul 20, 2004 5:29 pm

Isn't it possible for Creamware or some developer to make a device that is, let's say some sort of a marriage between the vdat and the sts5000, so we'd have audio recording and wave editing capabilities?
I'm not even talking about midi. Just a device that would allow you to record and edit audio within SFP.
Or some sort of device that could let you import audio clips and let you delay one clip from another across some sort of grid that could let you specify the time signature and the tempo.
I'm amazed Creamware hasn't come up with a solution like this after all this years.

Martin

Shayne White · Post by **Shayne White** » Tue Jul 20, 2004 5:46 pm

Well, I loaded up MiniMax and recorded some sounds into the STS at 32-bit, Sonar at 24-bit (32-bit ASIO), and an old version of Goldwave at 16-bit.

Goldwave might have sounded *slightly* worse than the STS -- not quite as "giving" in dynamics -- but Sonar sounded pretty much identical to the STS. Unless VDAT sounds infinitely more amazing than the STS, I'm going to stick with Sonar at 24-bit. It sounded great!

Shayne

decimator · Post by **decimator** » Tue Jul 20, 2004 5:53 pm

I also thought : VDAT ( got no DAT ) move along ...

NOW if you say that VDAT is a " What You Hear Is What You Get " I'am all attention !

I record the synths either in Sound Forge or SX2 and often I wonder : strange, there seems to be something lacking ...

Thanks for the head up !

Counterparts · Post by **Counterparts** » Wed Jul 21, 2004 3:19 am

marcuspocus wrote:

Yes, exactly, the audio is kept 32bit integer inside sfp (and vdat) while it goes to 32 float to pass thru driver at best (asio2-32 64), and get worst going thru wav driver (24bits). Also can add 'some' jitter due to OS layer.

Not a V-DAT man myself, but am interested in what you're saying here. I work in 24 bits usually, so presumably this mean that inside SFP, it'll be using 24 of its 32-bit internal precision(?) I use the ASIO-24 bit modules, so does this mean that the 24-bit integer is preserved over the interface between SFP & Cubase, or is it converted to 32-bit floating inside Cubase?

TIA,

Royston

Counterparts · Post by **Counterparts** » Wed Jul 21, 2004 3:20 am

[edit: dble post removed - out networking is so bad today I'd rather be at the dentist

]

[ This Message was edited by: Counterparts on 2004-07-21 06:22 ]

marcuspocus · Post by **marcuspocus** » Wed Jul 21, 2004 4:19 am

I don't know exactly what happen to stream going to drivers, but i actually would recommend using Asio2-32 64 src and destination modules.

It's lighter for cpu&mobo to process, even if there is in theory more bits.

Actually, with 24bits stream, cpu has to pad 8 more empty bits before sending data on the bus. PCI bus is 32bits. Not having to do this when using asio2 32 64 modules allow for more channel with less troubles.

Anyhow, it's how i understand it.

spiderman · Post by **spiderman** » Wed Jul 21, 2004 6:39 am

ok but actually do you use a kind of automation with a sync sequencer which manage the CC or do you use the vdat only for recording and then import tracks on the sequencer . or maybe you use only vdat and stm without automation ? i would like to know your workflow conserning the use of vdat .
thanks

[ This Message was edited by: spiderman on 2004-07-21 07:40 ]

spiderman · Post by **spiderman** » Wed Jul 21, 2004 6:45 am

hey I have a dream ! 8^)
it could be great if vdat manage special midi tracks along each audio track for the recording and the replay of midi cc ...

borg · Post by **borg** » Wed Jul 21, 2004 8:25 am

hi, just got vdat, and me too would like to know more about some vdat tips and other users' experiences. something to start with:

regarding the midi/sync. if you're also into modular and flexor, you could dedicate one track to a pulse signal and send it to flexor ramp modules. of course that still doesn't give you a lot of functionality outside modular.
however, you can use vdat together with the VRC-128 module and a midi sequencer. just tried it, and it works!
the vrc sends a clock signal to vdat, connect the midi out of the vrc to your sequencer midi module (or like i did, to the physical out (connected to the laptop)), and set up your midi sequencer so it accepts midi timecode.
i tried this with ableton live4 beta. and ableton followed ffwd, rwnd, start/stop from the vrc. haven't tested the tightness/accuracy, but it works...
must investigate this some more! looks very promissing.

blazesboylan · Post by **blazesboylan** » Wed Jul 21, 2004 12:00 pm

Marcuspocus: The ASIO 2 32 - 64 module is also, according to the manual, used for 24 bit. That's what I use it for, and my sequencer is set to 24 bit. Seems to work. I agree with your other ASIO points.

Borg: I prefer the VRC-S to the VRC-128. You can assign MIDI ccs to the buttons, and then use an external controller to start the sequencing. I found the MTC worked well with Nuendo. (Vegas, on the other hand, went splat.

)

Incidentally recording pulse signal on a spare track is often done in the film industry -- use up a channel for synch signal.

Spiderman: I agree the same functionality but designed for MIDI would be great. Maybe an "MDAT". I would keep the 2 modules separate though. Keep 'em simple!

Cheers,

Johann

marcuspocus · Post by **marcuspocus** » Wed Jul 21, 2004 2:15 pm

From the sfp manual P.10 of IO & drivers section :

1-ASIO2-32 source/dest 64: 2-64
channels, 24 or 32 bit integer.

Use this module for 24 bit recording.

2-ASIO2-Flt source/dest 64: 2-64
channels, 32 bit floating point.

Use this module for 32 bit recording with
Cubase VST.

So, as i understand, you use asio2-32 64 src/dest to make 32bits integer with soft that supports it, or you use asio2-flt 64 src/dest for 32 bits floating point recording in Cubase/Nuendo.

Both transmit 32 bits of data thru the bus. One transmit 24bits floating, so that's 32bits of data or 32bits integer, depending on the host.

The other (Asio2-flt) transmit also 32 bits.

Also, this note appear for Asio2 24 bits driver :

Instead of these modules, you can use
the newer ASIO1-32 source/dest 64
modules. The basic ASIO 24 Bit source/
dest modules are provided for
compatibility with earlier projects.

Anyway, no software that i know actually record 32bits integer, and also, if i understand it right, in theory 32bits floating is better, because it allow for a bigger headroom than 32bits integer.

These are the assumptions i have so far, considering my narrow understanding of all this.

After i have said this, why in hell then SFP sound so much better than most vst/vsti/dx plugins or hosts i've heard?

I'd say good for us

BTW, somebody know about an audio interface that allow you to choose between that much drivers? héhé...

[ This Message was edited by: marcuspocus on 2004-07-21 15:22 ]

[ This Message was edited by: marcuspocus on 2004-07-21 15:24 ]

blazesboylan · Post by **blazesboylan** » Wed Jul 21, 2004 3:28 pm

The ASIO 2 32-64 module is the one I use for recording 24 bit integer. I don't know ASIO2 protocol but I assume that the sequencer handshakes with SFP to say "Hey dude I want 24, not 32, on the ASIO bus". Anyone with ASIO2 insider knowledge know if this is true?

If anyone has ever developed a 24 bit floating point format I'd be surprised. 24 bit is integer only.

32 bit IEEE floating point is used by math coprocessors (actually 64 bit "double precision" coprocessors are more common these days). I assume that we'll all eventually be using software that deals ONLY with floating point numbers. However the benefit is really only inside the digital system, since analog-to-digital and digital-to-analog interfaces deal with finite voltage steps. It would be interesting to see a logarithmic-scale A-D converter that outputs floating points in dBFS or something, but I won't hold my breath.

Anyway floating point formatted numbers certainly give you much more precision than integers. They give you decimals and huge numbers, and basically an infinite dynamic range.

Well, not quite infinite. But compared to an integer from 0 to 4 billion (32 bit) or from 0 to 16 million (24 bit) or from 0 to 65 thousand (16 bit), floating points give you a *much* wider range of numbers to play with.

Notice, though, that even each different integer type provides several orders of magnitude better precision than the next.

Whether or not floating points make an audible difference over 24 bit integer audio I have my doubts. But from an audio software developer's point of view, floating points make perfect sense. Sequencers would be able to take advantage of powerful math coprocessors much more efficiently if they dealt exclusively with floating point data.

Sorry for rambling.

Cheers,

Johann

Stige · Post by **Stige** » Wed Jul 21, 2004 3:32 pm

floating point calculation can cause rounding errors due to limits of the cpu. Integer calculation is simplier math, no small numbers, no rounding errors.
Thats how I understand it.

Personally, I always prefer 32-bit integer higher quality than 32-bit float.

Once I tested SAW studio demo, and wondered why does it sound so clear and dynamic. SAW studio seems to be using integer audio engine (according to the settings I found there). Though the gui was really hmmm 'difficult'.

blazesboylan · Post by **blazesboylan** » Wed Jul 21, 2004 5:13 pm

Other way around.

Integers are whole numbers. Floating points have potentially infinite precision.

Math coprocessors do NOT use integers for sines, powers, etc. Check any ANSI C math.h file and you'll find that, in fact, everything is in "double" (64 bit) floating point format.

Integers are way old school in the realm of math.

at0m · Post by **at0m** » Wed Jul 21, 2004 6:54 pm

32bit float only has 24bit precision, while 32 integer has 32bit precision. The DSP cards use integer, do you often not have enough headroom? I use 24 for recording.

VDAT does 16, 24, 32 integer. I got it like a month ago and like it big time, but sync'ing SX2 to it doesn't work too well. I use VRC-128, send it to ASIO2's clock input thru VDAT's clock ports.

Hint on VDAT: I can't seem to rename the files in VDAT. So I rename the files from an explorer, then open the VDAT project with a text editor and correct the paths. Same way you could move some files to another drive...

What I also noticed is that VDAT uses a lot of CPU when running lots of tracks. Like 50% of my 2,533GHz P4 for 24 or 32 tracks. Running the same in Cubase uses only about 6% CPU!

Instead of adding a click track as b0rg does, I record a ramp of like 7 minutes and a version that is harmed to a basic 16-step pattern and one for pattern selection. I sync all patches to it: the sequencers and all modulations are driven from that ramp. It's also shaped to spit out MIDI CC# to the mixers and other non-modular stuff like effects for song automation. I don't use any MIDI in this song that I'm working on, it's completely ramp driven. Anyone in for a minimal experiment? Check out this tune, it's a 6.5mb example of this VDAT/flexor project. The only pre-fab effects used are EQ and reverb. It's still being worked on, it's itching to being imported to Cubase now for some chopping and arranging. Once edited, the tracks will run back thru the VDAT and modular mill. I'm having lots of fun with this zero native excursion

[edit] this version's been thru SX, you hear Supatrigger on the snare...

Also, in a heavier project, VRC-128 starts to act weird, for example I lost some parts when during recording tracks were armed and disarmed almost at random, automatically! :z I back up now, and delete VRC-128 once the project gets huge, to avoid the losses...

_________________
More has been done with less.

[ This Message was edited by: at0m|c on 2004-07-22 06:25 ]

blazesboylan · Post by **blazesboylan** » Wed Jul 21, 2004 7:23 pm

On 2004-07-21 19:54, at0m|c wrote:
32bit float only has 24bit precision, while 32 integer has 32bit precision. The DSP cards use integer, do you often not have enough headroom? I use 24 for recording.

*Sigh*. This "32bit float only has 24bit precision" is entirely misleading.

Integers represent whole numbers. Period. You cannot represent 7.9 with an integer. It will be rounded down to 7.

ANY math operation (i.e. effects, summing, etc) would be better off with floating point. Yes, you lose 8 bits of whole number precision. But you gain 8 bits of exponent. If you can find me a number that IS represented by a 32 bit integer but ISN'T represented in the 32 bit floating point domain then I'll send ya a Coke and a bag of chips, on the house.

If you don't believe me that floating point is more precise than integer, then here is a C program that divides 32 bit integers and 32 bit floating points by 3 and outputs the results:

Code: Select all

int main ( int argc, char * argv [] )
{
  int i;
  int my_int;
  float my_float;
 
  for (i = 1; i < 10; i ++)
  {
    my_int = i / 3;
    my_float = ((float) i) / 3.0;
 
    printf ( "32 bit int:   %d        / 3   = %dn", i, my_int );
    printf ( "32 bit float: %f / 3.0 = %fn", (float) i, my_float );
  }
 
  return 0;
}

Results:

Code: Select all

32 bit int:   1        / 3   = 0
32 bit float: 1.000000 / 3.0 = 0.333333
32 bit int:   2        / 3   = 0
32 bit float: 2.000000 / 3.0 = 0.666667
32 bit int:   3        / 3   = 1
32 bit float: 3.000000 / 3.0 = 1.000000
32 bit int:   4        / 3   = 1
32 bit float: 4.000000 / 3.0 = 1.333333
32 bit int:   5        / 3   = 1
32 bit float: 5.000000 / 3.0 = 1.666667
32 bit int:   6        / 3   = 2
32 bit float: 6.000000 / 3.0 = 2.000000
32 bit int:   7        / 3   = 2
32 bit float: 7.000000 / 3.0 = 2.333333
32 bit int:   8        / 3   = 2
32 bit float: 8.000000 / 3.0 = 2.666667
32 bit int:   9        / 3   = 3
32 bit float: 9.000000 / 3.0 = 3.000000

Notice the rounding errors in the 32 bit integer.

Like I said earlier I can't hear the difference. The difference is purely from a mathematical efficiency standpoint. Math coprocessors are optimized for floating point calculations. Even CPUs are often rated in terms of MFLOPS (million floating point operations per second).

Yes 24 bit integer sounds good to me.

Sorry for driving this thread so bloody far off-topic.

Johann

voidar · Post by **voidar** » Wed Jul 21, 2004 8:09 pm

Edit: Yeah, (2^24 * 2^8) = 2^32. So, f**k me.
---------

32bit floating point basically has infinite resolution due to the 8-bit multiplier which is included in the 32-bits. That is 24 bits + 8 bits = 32 bits. That is 2^24 * 2^8 audio steps, or something. (My head is not really working at this moment)

32bit integer I believe simply has 2^32 steps of audio precission, simply an extended version of 16 or 24 bits. It is vastly more limited than the above example.
This is a pure and simple technique and it might work better for audio.

Or I might be mistaken and they both work the same way, which would render the discussion pointless, as then it would be a matter of where you define your decimals.
As i.e. fixed point 1000000 is the same as floating point 0.000000.

Then again, I believe Creamware are a bit vague regarding whether they use interger or float.

[ This Message was edited by: voidar on 2004-07-21 21:25 ]

[ This Message was edited by: voidar on 2004-07-21 21:28 ]