PlanetZ forums - scopeusers.com

jksuperstar wrote:Nice day late April Fool's there, ronnie I think sometimes I might wish for a 6269db latency

ehasting wrote:we're....

Do tell?! I had no idea you were involved with bitwig?

Iwas just too lazy to add the quote symbol.. If i was involved. Scope support would be the only support bitwig would have

Hi,

I was a Beta tester for Bitwig in the first half of last year. Same as yourselves, I could not get Bitwig to reliably start its audio server - the process (engine-x86.exe I believe) would hang.
Bitwig support weren't forthcoming with a solution either. So, my ability to perform beta testing kinda crumbled...

Later last year, I had some stability issues with Ableton Live. I went on a spree of deleting old audio drivers, midi drivers, disabling Windows services, stopping startup items, scripting process kills... Generally, making my Win7 32-bit machine as lean and mean as I could.

Decided to try the Bitwig Release Candidate again about a month or six weeks ago. This time, Bitwig started!
I had deleted all ASIO drivers except Scope and my Focusrite Scarlett interface - including one for a Line6 POD X3, an older USB 1.1 Focusrite driver, and a Jack Audio installation.
And yes, Scope has to be started before launching Bitwig...

Bitwig is very nice.......
If I wasn't so heavily invested into Ableton Live, I would jump right on the Bitwig bandwagon. I might still, yet.

In the interest of accuracy...

So, Bitwig did indeed start last time some two months ago, on their 1.1.6 Release Candidate.
But - I tested it again last night. Yes, Bitwig did start when Scope was started, but I cannot see ASIO devices (I should have two connected devices - Scope 5.1, and a Focusrite Scarlett 6i6)... And in the other Audio API drop-down "Windows WASAPI", I can see Scope and Scarlett inputs, but only Scarlett outputs. The Scarlett outputs work fine, but the Scope inputs do not work. Not even sure what in my Scope Project I had running to say there would be any mention of Scope as an input device...?

Anyway, here's hoping Bitwig sorts this... They have a lovely product on their hands....

Not sure this will help anyone / trigger anything, but... in the interest of completeness....

The portaudio library is used as the audio interface to the OS for many applications. See a list here: http://www.portaudio.com/apps.html
So I tried an app from that list - Ambiloop - its a free sampler of your audio streams, can act as a delay etc.
With Scope started, and slaving to an external clock at 44.1kHz, in a project with six stereo ASIO Source channels and one stereo Asio Dest, I was able to start Ambiloop, and use its dialog to see and select Scope I/O. I loaded a wav sample, selected Scope Outs and Ins, selected the correct sample rate for Scope (44.1kHz), but I was warned that the sample I loaded was at 48, and suggested that there may be conversion distortion. Dismissing this warning popup, I could hear my sample, and I could see the wav playback in my Scope mixer's VU... So, Ambiloop (and by extension, portaudio) works OK with Scope.
Then went back into Ambiloop's Audio Chooser dialog, but the dialog and the application froze. Like there was something somewhere about having Scope selected that meant the dialog wouldn't be presented. Checking the Ambiloop install dir, I found a file "DeviceConfig.xml":
<!-- AmbiLoop Device Configuration -->
<!-- Generated by AmbiLoop Version 1.73 -->

<device_configuration>
<driver_type>3</driver_type>
<device_sample_rate>44100.000000</device_sample_rate>
<input_device_name>ASIO SCOPE</input_device_name>
<output_device_name>ASIO SCOPE</output_device_name>
<use_asio_preferrred_latency>1</use_asio_preferrred_latency>
<latency>2.902494</latency>
<input_channel>0</input_channel>
<output_channel>0</output_channel>
</device_configuration>

I have to delete this file if I want to start Ambiloop again without freezing. Which is funny, cause it had played audio thru to Scope in the previous session....

I also own (and dig!) LiquidRhythm, using it exclusively as a MaxForLive patch in Ableton. When I first bought LiquidRhythm, it had issues starting as a standalone app if Scope wasnt started, so I thought I would check what it looked like now... LiquidRhythm uses the Cycling74 Max 6.1 Runtime for Audio and Midi purposes, didnt think that the Max Runtime used portaudio. So, LiquidRhythm started fine. Loaded some samples, sequenced them, hit Play, audio played back fine. Checked what Defaults the Max Runtime had chosen - went to use ASIO (labelled "ad portaudio ASIO"!) and defaulted to the Focusrite Scarlett for Input and Output, and the correct sample rate of 44.1kHz for the Scarlett in its dedicated Sample Rate drop down. So, I chose Scope as ASIO Output, and the dialog defaulted to 11025Hz Sample Rate - the first item in the Sample Rate dropdown. Changing to the correct sample rate for the Scope project (44.1), a message similar to the Ambiloop dialog appeared in the Liquid Rhythm dialog. See attached.
Closed the dialog, hit play, no audio thru to Scope, but the app was working fine. Then went to open the Audio Settings dialog again, and freeze! Liquid Rhythm and its audio engine froze...

In conclusion... (phew!):
It seems that portaudio has a problem detecting which Sample Rate that Scope is running at. And selecting the correct sample rate may work once (as it did with Ambiloop), but it does not appear to be reliable (doesn't work at all with LiquidRhythm, and doesn't work 'a second time' with Ambiloop)... But, it can indeed use Scope if its configured correctly up-front (as it does with Ambiloop 'the first time').

I may be way off base but this seems like poor error handling to moi. Example: I select ASIO Config in Sonar for the SCOPE driver. Nada. No dialog box from SCOPE. That's always been the case. It looks like SCOPE does not like to have a DAW poke it's settings to boot. Fair enough. But Sonar doesn't care and does nothing but certainly doesn't send the driver packing. All is good, change your latency in SCOPE. Sonar keeps running with audio. Great! Mutual respect.

But what if a program like portaudio gets upset that SCOPE doesn't come back with a dialog for the DAW when you try to do ASIO configs from the DAW? Sounds like it goes into full revenge mode or just morons out. That's what it sounds like to me IMVHO. It looks like an error to the godlike DAW is interpreted as a full fledged revolt so it banishes SCOPE from the kingdom until some kind of reset happens. So much for user-friendly.

Scope is not capable of being configured by the app, period. a Scope card is not a soundcard, although it can function as one. it cannot respond to the queries being sent by Portaudio. if the guys at Portaudio cared, they wouldn't have made the app depend on handling soundcard settings.

garyb wrote:Scope is not capable of being configured by the app, period. a Scope card is not a soundcard, although it can function as one. it cannot respond to the queries being sent by Portaudio. if the guys at Portaudio cared, they wouldn't have made the app depend on handling soundcard settings.

EXACTAMENTO!

To be clear, the dialog doesn't come from scope. Portaudio needs to know what data format it needs to send to the asio endpoint. For that, it queries what sample rate scope currently is running at. Portaudio is not attempting to change anything in Scope!

Yes, it's some bad error handling in the portaudio library. But it seems that scopes response to queries about current data format doesn't conform to what portaudio expects. It isn't portaudio fault, nor is it scope fault. It's just a bug that could be fixed on either end, and since a bunch of asio clients don't have issue using scope, it makes most sense that it is addressed in the portaudio library. IMHO.

And, btw, there are no "guys at portaudio". It's an open source library. Anyone with the know-how can download the source, fix this bug, and submit their code change for inclusion in the next build.
Another reason to fix this on the portaudio side..

ahhh, my bad.


open source, ok that's what's up. someone will fix it.