Scope on ARM (Apple M1)

[garyb]

100'S of 1000's of dollars....want details? try making the product yourself.

Apple went to Intel and Unix because they were going out of business. Bill Gates bailed them out and sent them on a new path which forced users to buy everything all over again. this new move is another of the same. the original OS was future-proof, which was not profitable. people did not need new software when upgrading, and the new machines and old machines both worked with the Apple OS upgrades(until OSX).

here's a funny thing- i paraphrase from an old Apple ad- "only an idiot would use Unix. the Apple OS is superior for this and this reasons"
then, Apple made their loyal customers buy new machines that use Unix. another boondoggle.

i agree, it's about music, not machines, although much of what is currently called "music" is simply the operation of machines.

"I am a user, not a businessman. If I were a businessman I would not be commenting on this forum. I would go straight to talk to Holger and ask him 2 things:
1- What aspirations do you have with Scope?
2- what does he need to achieve these goals?"

this i can answer.
1. everything that everybody wants.
2. lots and lots of money.

Scope inside the DAW is actually kind of stupid. it castrates the system and eats resources. there are some serious technical issues involved, and then you end up with UAD, which is cool, but it's very limited. again, it's convenient and there is something to be said for that, but there is a good reason that XTC mode development was dropped in v3. Scope works differently and that is its strength. if you want to do everything completely inside the box, then that's a good thing, but you don't need Scope for that. still, afaik, XTC mode will return.

[valis]

One thing I will add though, is that my choice to use Scope in an external PC is *MY choice*, it still works fine integrated with a computer that can either host Scope PCI cards or the PCIe interface for Xite. My choice to use it alongside is dictated by the fact that I have other machines that are best suited to the way they are configured, and I choose to use Scope in that fashion as those machines are already fully loaded. This, in my opinion, is comparable to wanting an M1 Mac and Scope both. Since no ARM platform codebase for Scope exists, if one looked at Scope for what it is and wanted both it and the M1 Mac, this is how you would have to use it. Sure, things might change in the future, but it's best to be pragmatic with the tools at our disposal and use them to the best of our abillity.

Beyond that, all of this is but a fart in a windstorm, as Gary has also stated. GaryB may have some line to Holger, but I would presume Holger has to balance Gary's feedback against his own goals and whatever other objectives he has in life & work. I only know Holger from 1-2 communications and seeing posts on facebook. That means while it might *seem* like I have some grip on the Scope platform, it's really only my stewardship of this forum that gives me any insight into this platform (well that and being a user). And GaryB is a continent away helping steward this forum and supporting the users as best as he can.

So long-winded missives on these forums will do what? You may have some potential into whipping up a few of the users into a small mob that can...just continue to post long winded missives? What's the point really? It comes off more at ire at Scope not being suited to your needs, which of course means you should look at the overall offerings in the market and see what does. Or, as mentioned above, approach the situation pragmatically.

I'd rather not continue to go point by point on posts as it's time consuming and doesn't accomplish much. Yet you're free to express yourself regardless of course.

[dawman]

I want reverse XTC.

Put all of my ASIO FX in Scopes AUXs like pitch shift, phase, delay and reverb.
Then use Scopes strength which is Dynamics and automation, not to mention MIDI Devices and Snapsjots from SAL Und Speilraum.

I can wait till the Cows come home because everything I need and use works, no need to upgrade, fix, tweak. Just play and make music.

[dante]

Scope inside the DAW is actually kind of stupid. it castrates the system and eats resources. there are some serious technical issues involved, and then you end up with UAD, which is cool, but it's very limited. again, it's convenient and there is something to be said for that, but there is a good reason that XTC mode development was dropped in v3. Scope works differently and that is its strength. if you want to do everything completely inside the box, then that's a good thing, but you don't need Scope for that. still, afaik, XTC mode will return.

AUD Apollo Console runs independantly of DAW. I can plug in guitar, use a unison overdrive pedal for impedance matching then insert an chorus and amp sim and get a great latency free sound. So not sure allowing Scope device to run as a VST forces it to be limited *because UAD does that* - since UAD can run both within and independant of DAW. XTC mode is either a good thing to have in Scope arsenal or its not. If it is, overcome the technical issues (as others have done).

[garyb]

so easy to say...

good for UAD. running Scope devices as vsts definitely, 100%, eats resources and limits the system, period. it doesn't mean that XTC mode won't return.

[dante]

Everything eats resources - the important question is - how much resources relative to using same devices over ASIO. Or, how much resources it uses over XITE PCIe vs the old cards over PCI. I'm assuming here that XTC has never been run on XITE PCIe (other than Holger testing if he's got that far). Will be interesting to put all that to the test if and when it comes back.

[fra77x2]

the test has been made and you can also have a clear understanding in your head. we have the cpu and the dsps. everytime a signal has to travel between them there is latency because the signal has to go to the dsps and then rerouted to the cpu. if you insert in the daw channel fx one vst then another dsp calculated, then another to the cpu and so on the latency grows. this also costs in communication signals that we know that this resource is limited. there is a dedicated dsp that is used for sending and receiving signals. Some workaround was to use a multifx in the daw so to load several dsp calculated plugins in a row and so have only one path of latency. but this is already a workaround. Signals do not go around with magic. My opinion is that if you care about such approaches there is something wrong with your methodology. you want stuff to suit to you but almost always what can be done has already been tried. Xtc seemed to work but anyone who has tried it knows the result. it doesn't. For me these are useless discussions and hopes based on imagination and not willing to understand the basics of computing. For me the decision to abandon xtc was the right one so to not spare the users time with no really working functionality that is good only in imagination and in small letters advertising. wow xtc... The decision to bring it back for me is not right.
it is actually weird to put together all these mega machines and at the end of the day to discuss how to achieve such workflows. Find a way to use the existing functionality and don't spare your time with unecessary not working methods. Each project is already an entity. it contains the daw project the audio files etc. it can also contain a scope project. whats the deal? if you care about automation of scope plugins then... learn to live without it. for me anyway drawing automation for a big number of tracks or fx rarely work because my brain gets fatigue. so i have a different procedure.... perhaps other people are smarter but i doubt....

[dante]

I have no need or intention of using XTC for chaining Scope DSP effects VST - to me that may involve sending a signal to scope for an EQ - it comes back to DAW - then send it into Scope Compressor and back. So therefore each effect in series involves a round trip to DSP.

I can do that already using Reason. I can chain UAD VST from a Guitar track 3 or 4 in series and have no problem. If Scope cant do that, to me its not a bad use case but a limitation of Scope, where its better to make one round trip by doing the chain of 2 or 3 effects inside the Scope project.

However, chaining effects is not my use case for Scope XTC. Nor is any automation. Its more about synth track render in place (eg proTone) - even if its no faster than playback speed. That's a single round trip.

if Holger intends to implement XTC Ill take it that its feasible on XITE and worth doing and explore its limits. If he deems it not feasible then so be it.

[fra77x2]

My friend it s not a limitation of scope neither you can do it with Uad. stop finding limitations everywhere. try to learn and stop complaining. hit the fcking record and go. perhaps you are dissapointed by your output and turn back a sadistic behaviour to the world.

[valis]

Pretty sure it's been stated that XTC mode was on the list of things to do, it's just that the hurdles were such that it's not been done yet. I don't think those hurdles were on the Scope side, but rather the native side of things that is a bit of a moving target.

And UAD made this addition largely for the same reason MOTU/RME/Presonus etc have some basic DSP on offer as well, for realtime monitoring of the same effects that you'll presumably use in your DAW session when mixing. UAD has improved on their original model by moving to our DSP chips some years back (the first UAD accellerators were GPU's that failed and were rebranded), creating their own i/o boxes so they don't have to contend with the dizzying array of soundcards out there (that was a HUGE hassle for many, mostly because most of those soundcards had shitty drivers or logic components), and of course UAD has their business model which is focused around branded models of hardware. This is still a huge part of their appeal, but yes the flexibility of their recent offerings has increased a lot.

I have little use for XTC, but don't mind if people use it if and when it exists. Hurts me none. Gary says it eats resources & limits the system, and this is exactly correct. I'll reiterate what I've said before, even though I'm sure most of us know this already:

Before 'plugin delay compensation' existed (or in Pro Tools parlance, ADC (Automatic Delay Compensation)), simply bussing a parallel compression scheme in your DAW (or even digital mixers) created phasing. To fix this you had to 1. be able to hear it and 2. be able to measure the number of samples that compressor delayed things and then compensate. Pro Tools had manual values that engineers had to enter by hand, and many VST/AU devs published their known values as well for manual compensation (we used to use the sample delay parameter on the audio track's header object in Logic to do this for instance). Some plugin makers (like Waves) offered 2 versions of plugins, 1 intended for final mixing (L3 has a HUGE latency) and 1 for tracking in realtime, so this added additional work.

Most people simply used those values to keep multitracked sessions phase coherent, for instance a multi-mic'd drum recording or band members all playing at once. Doing complex routing then was a PITA, regardless of DAW. Then came the DSP cards with host integration...

What happened then, happened regardless of platform. When using UAD/Powercore/XTC etc, Phase relationships changed everytime your DAW was open, and sometimes just by adding new FX that used the DSP system. The more complex the routing, the more manual labor (thinking) required. These were, by modern standards, VERY simple routings still. Plugin Delay Compensation kept evolving until all of those issues were accounted for, but what that means is that behind the scenes not only was considerably more traffic being sent across the system bus but also a ton of additional host buffers are created for each additional delay compensation that occurs when you were doing any kind of complex routing.

Ie, with just track inserts, the host will simply delay reading audio data to keep things phase coherent when possible. but as your routing becomes more complex (bussing, parallel mixing, output inserts, etc) then it becomes necessary to buffer ALL data that has to time align with this late arriving track. So if you keep piling on the routing, it's possible to be carrying the equivalent of 50-60 'channels' of audio data back & forth to the dsp chips on TOP of the ASIO buffers, PLUS the numerous additional host buffers as required for any bussing or parallel mixing etc. All of this eats headroom for moving this data around in RAM & via i/o buffers.

Suffice it to say that before UAD had an integrated soundcard, someone measured a complex project with 36 asio channels active as creating several hundred buffers behind the scenes. This wasn't even really possible with manual compensation, but it also brought the host computer to its knees with what would have been only a small CPU load otherwise from native effects (something akin to 15% cpu used for calculating native effects, and the i/o for the dsp card was bottlenecking the system and causing buffer underruns). This is why UAD had problems in the past when being mixed with various soundcards, some held up better than others with all of this system traffic contending with their DSP cards as well. A situation we know well from Scope, and if you read back you'll find evidence that PCI overflows were more common with XTC users than pure DSP folks.

This of course was over a decade ago, and computers are powerful enough that this is largely transparent now. But GaryB is correct, the amount of data being moved and the burden placed on the host system DOES increase rather dramatically.

Long story short, the fact that PDC/ADC 'hides' the complexity of keeping all of this in phase means it's very easy to create situations that burden the host system far more than is obvious as an end user, and this is not a very efficient way of working. WIth the power of native now, it's also not strictly necessary.

Also dante, the comparison to Reason isn't really valid as using Reason via a VST rack or Rewire aren't comparable to carrying data across the system bus to a soundcard or dsp card. Plus... are you able to use XTC & 'render in place' with harrison?

[dante]

Wasn’t referring to using Reason Rack Plugin - more chaining UAD guitar effects within reason placed after say Shreddage.

Using Harrison just fir mix / mastering (after scope synths already rendered to audio) so latency not an issue there, even when using the highest latency mastering plugin.

[Bud Weiser]

Also dante, the comparison to Reason isn't really valid as using Reason via a VST rack or Rewire aren't comparable to carrying data across the system bus to a soundcard or dsp card. Plus... are you able to use XTC & 'render in place' with harrison?

He also mentioned UAD because it´s Sharc DSP based.

I don´t understand the metamorphosis of the thread at all though.
All the discussion about ARM (Apple M1) has nothing to do w/ page #2 or #3 now.

I hope Holger focus on SCOPE 7.1 !
For PC !



Bud

[valis]

Wasn’t referring to using Reason Rack Plugin - more chaining UAD guitar effects within reason placed after say Shreddage.

Using Harrison just fir mix / mastering (after scope synths already rendered to audio) so latency not an issue there, even when using the highest latency mastering plugin.

Gotcha. I have a current version of Reason but don't use it enough to be as familiar as you are. And correct, mix/mastering was originally the workflow that UAD targeted best, so that makes sense in harrison. Clearly computers and interfaces have evolved enough that the latency penalty for the player isn't the issue that it once was (in Logic we also have a button that either disables plugins or automatically switches them into a low-latency mode). I did account for that in my above post...

Also dante, the comparison to Reason isn't really valid as using Reason via a VST rack or Rewire aren't comparable to carrying data across the system bus to a soundcard or dsp card. Plus... are you able to use XTC & 'render in place' with harrison?

He also mentioned UAD because it´s Sharc DSP based.

I don´t understand the metamorphosis of the tread at all though.
All the discussion about ARM (Apple M1) has nothing to do w/ page #2 or #3 now.

I hope Holger focus on SCOPE 7.1 !
For PC !



Bud

Well, clearly we wound up discussing XTC as it's something that SonicCore is presumably working on for a V7 release candidate, and that's related to an overall discussion of development paths users would like to see (such as the M1 suggestion in this thread).

Also, I did account for UAD moving to SHARC (though I said something akin to 'our DSPs' I meant A.D. Sharcs).

[Bud Weiser]

Well, clearly we wound up discussing XTC as it's something that SonicCore is presumably working on for a V7 release candidate, and that's related to an overall discussion of development paths users would like to see (such as the M1 suggestion in this thread).

I don´t find the post a.t.m,- but some time ago, someone talked to S|C support and reported here in the forum, S|C is working on something which might need about 1 year until release and working on Mac.
He also reported it won´t be SCOPE and SCOPE, as we know it, will never be available for Mac.
When I read, I said to myself "they´re juming on the ARM (M1) train now, but w/ a new and different software product".

That´s good, even I´m not a user of any Intel based Macs at all,- I only use PPC for the old applications like Sounddiver.

OTOH, we all know S|C planned to release XTC as a separate application and not only for Mac.
That´s why we didn´t find it in actual SCOPE v7 releases.
I´m pretty sure this XTC release will come sooner or later.

BUT,- XTC was related to SCOPE always,- so I´m somewhat irritated now.



Bud

[valis]

I recall the post, but know nothing about that otherwise.

[garyb]

me neither.

[dante]

I went OT (onto XTC) in response to something Gary said about Scope inside the DAW being actually something stupid.

@valis, my typical Reason usage is below, with 3 instances of Shreddage e.g. going off in series to a native VST then 2 instances (each) of DSP plugins. I can play/record these guitars via Scope MIDI in real time jamming along with the track playing back with no noticable latency (@96Khz), native DSP hovering around the 30 - 40% mark and UAD DSP around the same mark.

So I imagine my use case for Scope XTC would be a lot more modest with less round trips etc and no realtime requirement (rendering a Scope synth to audio whilst I sit back and wait).

XTC would be more about workflow for me than breaking system or realtime records - the convenience of having proTone or Ocean Storm set up in the DAW - no need for a separate Scope project with its routing ( & loopback for rendering), since the VST architecture itself would take care of the routing (as it does when I drag and drop a Brigade Chorus between BIAS Pedal and Diezel Amp).

Reason Guitars

Reason Guitars Small.jpg (262.08 KiB) Viewed 1655 times

[garyb]

it is something stupid, but it's great for commercials!

[valis]

Appreciate you sharing your workflow. Also note I was explaining why GaryB was saying that DSP integration with DAWs is inneffecient, not stating it doesn't work.

[dante]

DSP integration with DAWs is inneffecient.

Of course it is, unless the DSP is baked into the DAW by design.