This is a tad off topic but I achieve 0 latency with 1024 byte asio buffers.

I split the mics as they come in with a mixer. The preamp outs of the mixer go to the DAW to be recorded. The insert (outs) go to another mixer in the tracking room and act as a "you mix it" cue mix.

The incoming overdubs are lined up with the previous tracks by the asio latency setting in aud.ini.

All this because Sonar does not support ASIO DM but it works and is reliable.

So we rally tonight!!

Yea I get it and I realize English may not be your first language so I and others cut you some slack. But there is no standard. It is a foolish business venture at best to support ADM with no standard in place. There are any number of ways that hardware can support DM and until that methodology is standardized there will probably not be any support for ADM in sonar.

  if America had taken that attitude had never traveled to the moon and won the space race...or  Columbus discover America... 

rabeach

carlosagm79

Yea I get it and I realize English may not be your first language so I and others cut you some slack. But there is no standard. It is a foolish business venture at best to support ADM with no standard in place. There are any number of ways that hardware can support DM and until that methodology is standardized there will probably not be any support for ADM in sonar.

if America had taken that attitude had never traveled to the moon and won the space race...or  Columbus discover America... 

Columbus did not discover America and there is no proof anyone actually went to the moon and a great deal of evidence to the contrary.

With this attitude the Wright brothers would never have flown a machine heavier than air, and with a system of thought like yours , we still lived in medieval speculative ignorance, que verguenza leer tus palabras!

rabeach

que verguenza leer tus palabras

okay no offence intended carry on.

I'm not offended, and I hope you do not,
I just feel it's a shame that exist people who think like you in the world
but yeah forget it, carry on

Well that was a fun read...

Can I get any takers on any of the following -

=> The audio engine in X1 sounds better/worse than Sonar v8
=> Sonar's audio engine doesn't sound as good as <insert brand XX> here
=> There's no need to record at 24-bit depth
=> Gold plated audio cables sound better
=> Running an EQ in front of your monitors is better than treating your room
=> Sonar doesn't pan properly
=> Anything with a 20-40% claim...

:D:D:D

FWIW - I'd like ADM implemented too!

:) Q.

rabeach
and there is no proof anyone actually went to the moon and a great deal of evidence to the contrary. 

Hey I love a good conspiracy theory as much as the next person, but this sentence wins my "Tin Foil Hat" award of the day.

UnderTow

rabeach


Yea I get it and I realize English may not be your first language so I and others cut you some slack. But there is no standard. It is a foolish business venture at best to support ADM with no standard in place. There are any number of ways that hardware can support DM and until that methodology is standardized there will probably not be any support for ADM in sonar.

What a complete load of non-sense. ADM is the standard and it is defined in the ASIO SDK downloadable here: http://www.steinberg.net/en/company/developer.html

UnderTow

I can't open that site.

bitman

rabeach

UnderTow

rabeach


Yea I get it and I realize English may not be your first language so I and others cut you some slack. But there is no standard. It is a foolish business venture at best to support ADM with no standard in place. There are any number of ways that hardware can support DM and until that methodology is standardized there will probably not be any support for ADM in sonar.

What a complete load of non-sense. ADM is the standard and it is defined in the ASIO SDK downloadable here: http://www.steinberg.net/en/company/developer.html

UnderTow

I can't open that site.

I can. Maybe you're not a developer.

- Just kiddin man

Yes I'm not and ASIO developer. <g> Just curious, here is Noel response "... ASIO DM is one of the poorest areas of the ASIO specification and very incomplete. We ran into so many vague areas with the ASIO spec and differences in manufacturers implementations that we ultimately ended up scrapping it. Additionally most if not all HW vendors have their own console applications that implement their own custom direct monitoring mapping that is superior than any host based ASIO DM implementation could rival." If the specification is not well written and vague and allows for independent custom application how can anyone support it in a software host. My point earlier that UnderTow indicated was non-sense was that if hardware manufacturers are implementing custom versions of direct monitoring then there is no hardware standard in use. If I'm wrong then I'm wrong. If UnderTow will provide an explanation as to why that is not true. I'm happy to admit my error.

rabeach


Yes I'm not and ASIO developer. <g> Just curious, here is Noel response "... ASIO DM is one of the poorest areas of the ASIO specification and very incomplete. We ran into so many vague areas with the ASIO spec and differences in manufacturers implementations that we ultimately ended up scrapping it. Additionally most if not all HW vendors have their own console applications that implement their own custom direct monitoring mapping that is superior than any host based ASIO DM implementation could rival."

So you are just parroting Noel's unsubstantiated remarks and not adding anything but noise to the discussion? Great.

If the specification is not well written and vague and allows for independent custom application how can anyone support it in a software host. My point earlier that UnderTow indicated was non-sense was that if hardware manufacturers are implementing custom versions of direct monitoring then there is no hardware standard in use. If I'm wrong then I'm wrong. If UnderTow will provide an explanation as to why that is not true. I'm happy to admit my error.

I already have. In this very thread. ADM consists of 5 parameters which are defined in the ASIO SDK and which I have quoted in a previous post here. If Noel or someone else at Cakewalk can explain what is so vague about those 5 parameters and why Cakewalk can not implement what quite a few other companies manage to implement successfully, then they might have a point. At the moment it is just Noel and Willy pointing fingers without any real argumentation.

If Cakewalk don't want to implement ADM for whatever reason that is fine but basically saying they can't do what other companies manage to do just fine is a bit silly IMO.

UnderTow

...wicked

rabeach
and there is no proof anyone actually went to the moon and a great deal of evidence to the contrary. 

Hey I love a good conspiracy theory as much as the next person, but this sentence wins my "Tin Foil Hat" award of the day.

No, it's reely reely trooooo!!!  Here's proof!!!!   <g>

http://www.youtube.com/watch?v=7_GzwzaJuwY

I already have. In this very thread. ADM consists of 5 parameters which are defined in the ASIO SDK and which I have quoted in a previous post here. If Noel or someone else at Cakewalk can explain what is so vague about those 5 parameters and why Cakewalk can not implement what quite a few other companies manage to implement successfully, then they might have a point. At the moment it is just Noel and Willy pointing fingers without any real argumentation. If Cakewalk don't want to implement ADM for whatever reason that is fine but basically saying they can't do what other companies manage to do just fine is a bit silly IMO.

I don't know how we can make it anymore clear for you, 5 parameters in a spec does not mean that every device will respond to those 5 parameters the same.  We can implement it and as Noel said in that other thread in reference - we did in SONAR 8, I used it myself with a few RME devices at the time.  The only finger pointing is you pointing and questioning us.  The assertion that we are incapable or not willing is ridiculous - ASIO is not rocket science.  Reasons why it was pulled:

• It does not work consistently across the board with all ASIO devices
• Most devices have a superior mixer anyway

Finally, ASIO is not a standard, widely adopted - absolutely but it's a spec that can be changed, updated or modified at any time without any regards to compatibility.

Willy Jones [Cakewalk
]

I already have. In this very thread. ADM consists of 5 parameters which are defined in the ASIO SDK and which I have quoted in a previous post here. If Noel or someone else at Cakewalk can explain what is so vague about those 5 parameters and why Cakewalk can not implement what quite a few other companies manage to implement successfully, then they might have a point. At the moment it is just Noel and Willy pointing fingers without any real argumentation. If Cakewalk don't want to implement ADM for whatever reason that is fine but basically saying they can't do what other companies manage to do just fine is a bit silly IMO.

I don't know how we can make it anymore clear for you, 5 parameters in a spec does not mean that every device will respond to those 5 parameters the same.

Do you really have to ask? By clarifying what vagueness or ambiguity there might be. You can keep claiming that things are unclear but other manufacturers have managed to implement it so clearly it can't be as hard as you are suggesting.

We can implement it and as Noel said in that other thread in reference - we did in SONAR 8, I used it myself with a few RME devices at the time.  The only finger pointing is you pointing and questioning us.

Bull$hit. Noel and you are pointing your fingers at the ADM specification and therefore, by implication, at Steinberg. You started playing that game when there really was no need to do that. I am just responding to your unsupported claims.  Frankly it would have been smarter of you guys to just not respond to those specific queries. Pointing fingers at another company without backing up your claims with very clear and unambiguous proof looks very weak and unprofessional IMO. It might sail with the fanboys but I need some real proof to be convinced. (I'm not saying there isn't but so far all you have done is point).

If there are areas that are really vague and ambiguous, point them out. Otherwise your claims are empty.

 The assertion that we are incapable or not willing is ridiculous - ASIO is not rocket science.  Reasons why it was pulled:

• It does not work consistently across the board with all ASIO devices

Nor does it need to as long as unsupported parameters are ignored by the devices. That is how the specs are defined. If the devices do not follow the specs, that is a different issue and a problem for the manufacturers of those devices. Still, I find it a bit strange because if they don't follow the spec, they wouldn't work with other DAWs supporting ADM either.

There are only 5 parameters. Here they are again with my own commentary behind in red:

typedef struct ASIOInputMonitor
{
    long input;        // this input was set to monitor (or off), -1: all                    // Source input number or -1 for all inputs.
    long output;    // suggested output for monitoring the input (if so)             // Destination Output number.  (1st of stereo pair)
    long gain;        // suggested gain, ranging 0 - 0x7fffffffL (-inf to +12 dB)    //  Gain level of the Input source defined above.
    ASIOBool state;    // ASIOTrue => on, ASIOFalse => off                              // On or Off (Are we monitoring this input or not?)
    long pan;        // suggested pan, 0 => all left, 0x7fffffff => right                 //  Panorama value
} ASIOInputMonitor;

The only slightly confusing comment in the sepcifications is the following: "Output is the base channel of a stereo channel pair, i.e. output is always an even channel (0,2,4...). If an odd input channel should be monitored and no panning or output routing can be
applied, the driver has to use the next higher output (imply a hard right pan)." but even that makes sense if you keep in mind that ADM assumes a stereo output.

I really have a hard time seeing which part is unclear.

• Most devices have a superior mixer anyway

True and this is a valid point. Still I think that the argument that it is practical and useful to be able to control basic routing for monitoring purposes directly from the same host software weighs in as a strong counter argument.

Finally, ASIO is not a standard, widely adopted - absolutely but it's a spec that can be changed, updated or modified at any time without any regards to compatibility.

It is a de facto standard and you know it. And anyway, the minute Cakewalk implemented ASIO and VST, that argument flew out the window. Hey I am all for truly independent standards for both plugins and sound card interfacing but no one seems interested enough at the moment to make that happen. So, for now, we have to do with the (de facto) standards like ASIO, VST, Rewire, EuCon, HUI and of course, MIDI.

And again, if Cakewalk simply decide that they don't want to support ADM that is fine but I just don't see which part of the specs are unclear or vague.

UnderTow

Haha, UnderTow loves himself a good donneybrook. He always seems capable of supporting his rants tho so what can ya do? Sure he can use a "nice pill" but he does go the distance to back his verbiage up.

John

I do care about how Noel and Seth are spoken to here.

It is Willy, not Seth. That just shows how much you really care John.

Stop IT now!

You are not the forum police John.

By acting the way you are all it can do is make them think twice about ever coming here again.

They should not point fingers at other companies unless they can support their claims. That is something to think of. For the rest there is no reason for them not to come here. If you were not such a fanboy you would see that.

This behavior on your part is effecting me as stated above. So back off.

Feel free to put me on ignore John. That is what the function is for. And anyway, this isn't your forum. How things affect you personally are rather irrelevant. But you are probably just pouncing at the first possible opportunity to get back at me for pointing out that you derail perfectly good threads with your fanboy behaviour.

I want them coming here whenever they want and feel welcome. You are not helping that idea.

I am asking very specific questions in a response to claims that Noel and Willy have made. If they can back up their claims, there is nothing wrong with the questions. If they can't back up their claims or simply don't want to, they shouldn't make the claims in the first place.

Also I do not want you banned but I think you are at the the point where it may happen.

Which comment is that offensive? The one where I call bullsh1t? Where I point out that it is indeed Noel and Willy pointing fingers? In other words where I defend myself against a claim Willy makes about my posts? He claims I am pointing fingers. That really is bull$hit. Yeah I am critical but what is new? I wish more users were...

Rethink what is so darn important that you are risking it all for what?

Oh the drama. My points are very clear but you do not bring a single argument against any of the points which tells me you just can't stand any criticism of Cakewalk and are being your usual fanboy self.

I make simple and clear points that I back up with facts and references. If Willy or whomever from Cakewalk want to argue with me, they can but if I disagree I will come back with more facts and more references. If you don't like that John, feel free to block me. If Cakewalk don't like that, they can either ignore me or ban me or whatever.

UnderTow