Hi,
There is something awry with my Scope installation I believe...
The symptom is that I cannot start any application that depends on the Portaudio library, for interfacing general applications with ASIO streams.
Such apps as those listed in the title of this thread...
Ableton, Reaper, and some other hosts, do not have an issue starting. Believe these apps do not use Portaudio...
I am nearly sure that Scope is the root of the issue. Up til recently, I could only start those applications when Scope was started... Now, in the last couple of weeks, I cannot start these applications at all, Scope started or not...
So, the natural course of action would be to uninstall Scope, and re-install.
Does the Scope Installer know to delete redundant entries from my Registry? Like Audio Endpoints that were never properly cleaned up in the past?
Is there a known good strategy for getting my stuff back?
I will have installed third party software into Scope, some pay-for devices and some freebies... Will the uninstaller leave my third-party files in place?
Ive taken a copy of my Scope installation - and afaik, the following paths should have me covered, to copy them back over on top of a new installation:
C:\Program Files\SCOPE PCI\App\Dll
C:\Program Files\SCOPE PCI\App\Dsp
C:\Program Files\SCOPE PCI\Modular Modules
C:\Program Files\SCOPE PCI\Devices
C:\Program Files\SCOPE PCI\Presets
C:\Program Files\SCOPE PCI\App\Bin\cset.ini
C:\Program Files\SCOPE PCI\App\Bin\keyfile.v5
Any advice gratefully accepted...
Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig, Max
Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig, Max
Not because it is easy, but because it is hard...
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
afaik, any bad entries should be overwritten simply by rerunning the installer. i would try this first. if you do uninstall, make a copy of the dsp, sys, devices, presets and script folders. you can then overwrite the new folders with the old ones to get your stuff back. basically your list and this one will cover everything. rerunning the installer without uninstalling should leave all your user changes intact.
you know, there are some apps, mostly consumer based, but also some "pro" apps, that attempt to setup the soundcard automatically. the pronlem is that Scope cards aren't soundcards. these apps don't simply time out when they get no response to their queries, they crash and then the Scope driver appears to be the cause. sure, this is an oversimplification....
you know, there are some apps, mostly consumer based, but also some "pro" apps, that attempt to setup the soundcard automatically. the pronlem is that Scope cards aren't soundcards. these apps don't simply time out when they get no response to their queries, they crash and then the Scope driver appears to be the cause. sure, this is an oversimplification....
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
Check this thread from earlier this year. Verdict was portaudio sucks.
http://forums.planetz.com/viewtopic.php ... =portaudio
http://forums.planetz.com/viewtopic.php ... =portaudio
"I’ve come to the conclusion that synths are like potatoes, they’re no good raw—you’ve got to cook ‘em, and I cooked these sounds for months before I got them to the point where they sounded musical to me." Lyle Mays
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
Haha - thank you (again) ronnie! I weighed in at the end of that very thread myself - I forgot how widespread this problem was in the Scope Community! And I always blamed myself :-O
I have just downloaded the portaudio source there, and installed Microsoft Visual Studio. Thanks for finding that post on stackoverflow! Its all good info.
I may be able to build a new portaudio.dll that has a fix in for this... I really do not know at this point... As for linking that portaudio library build with those failing apps - again, I do not know if putting my portaudio.dll "higher up" in the Lib search path means it will resolve the entry points to my build of portaudio.dll??
Note that I have gone backwards of late with portaudio apps and Scope, so I hope to be able to get to a point where having Scope started means I can start these apps again...
FYI, installed Jack Audio for Windows again here, and ran this:
C:\Program Files\Jack\jackd -d portaudio -l
I notice the following entry when Scope is not running:
[ Default ASIO Input ]
[ Default ASIO Output ]
Name = ASIO::ASIO SCOPE
Max inputs = 0
Max outputs = 0
ASIO minimum buffer size = 128
ASIO maximum buffer size = 128
ASIO preferred buffer size = 128
ASIO buffer granularity = power of 2
Default sample rate = 44100.00
Looks like the problem the guy in stackexchange may have had... But here, I think its just what Scope returns when Scope is not started...
And when Scope is running:
[ Default ASIO Input ]
[ Default ASIO Output ]
Name = ASIO::ASIO SCOPE
Max inputs = 2
Max outputs = 12
ASIO minimum buffer size = 128
ASIO maximum buffer size = 128
ASIO preferred buffer size = 128
ASIO buffer granularity = power of 2
Default sample rate = 44100.00
The number of ASIO Ins and Outs match my current Scope project here.
I also notice that Scope is listed with [ Default ASIO Input ] and [ Default ASIO Output ] tags - my two other ASIO drivers are not default - I wonder if Scope being marked as the Default ASIO Driver on my machine has further negative impact? I will have to check how Windows reports what ASIO interface is "default"...
For me, the portaudio library is indeed used by professional software. All the software listed in the title of this post qualifies as pro-audio software. I think the issue here is that portaudio is trying and failing to "ping" or maybe apply defaults to Scope ASIO (which it cannot), and is not handling the error that the Scope ASIO driver raises with that attempt.
Portaudio apps work fine with a Focusrite Scarlett ASIO driver, and Motu ASIO driver... There is something in the implementation of the ASIO standard that the Scope ASIO driver is not conforming to the API spec, and the portaudio library is crapping out in some bad / inappropriate (read: crashy!) way as a result. Other apps do not have this problem, so portaudio needs to gracefully handle that error... Other apps - Ableton, Cubase, Reason, Reaper, etc. - must handle that condition appropriately...
I will see how I get on with compiling portaudio.dll. It is open-source after all - if I have a chance to test portaudio scanning my system for Audio endpoints, I should be able to find the bug, and if I find a fix for the bug, I may then look at submitting it to the portaudio trunk..... Would most likely need to be pushed out as some kinda rebuild patch for affected apps tho - dunno if these apps just dynamically link to the off-the-shelf portaudio.dll, or if they have themselves included portaudio source code in their app, and customised it a bit themselves, which would be harder to get released across the dev cycles across multiple app vendors....
Anyway, should I have any progress, I will let ye know.
I have just downloaded the portaudio source there, and installed Microsoft Visual Studio. Thanks for finding that post on stackoverflow! Its all good info.
I may be able to build a new portaudio.dll that has a fix in for this... I really do not know at this point... As for linking that portaudio library build with those failing apps - again, I do not know if putting my portaudio.dll "higher up" in the Lib search path means it will resolve the entry points to my build of portaudio.dll??
Note that I have gone backwards of late with portaudio apps and Scope, so I hope to be able to get to a point where having Scope started means I can start these apps again...
FYI, installed Jack Audio for Windows again here, and ran this:
C:\Program Files\Jack\jackd -d portaudio -l
I notice the following entry when Scope is not running:
[ Default ASIO Input ]
[ Default ASIO Output ]
Name = ASIO::ASIO SCOPE
Max inputs = 0
Max outputs = 0
ASIO minimum buffer size = 128
ASIO maximum buffer size = 128
ASIO preferred buffer size = 128
ASIO buffer granularity = power of 2
Default sample rate = 44100.00
Looks like the problem the guy in stackexchange may have had... But here, I think its just what Scope returns when Scope is not started...
And when Scope is running:
[ Default ASIO Input ]
[ Default ASIO Output ]
Name = ASIO::ASIO SCOPE
Max inputs = 2
Max outputs = 12
ASIO minimum buffer size = 128
ASIO maximum buffer size = 128
ASIO preferred buffer size = 128
ASIO buffer granularity = power of 2
Default sample rate = 44100.00
The number of ASIO Ins and Outs match my current Scope project here.
I also notice that Scope is listed with [ Default ASIO Input ] and [ Default ASIO Output ] tags - my two other ASIO drivers are not default - I wonder if Scope being marked as the Default ASIO Driver on my machine has further negative impact? I will have to check how Windows reports what ASIO interface is "default"...
For me, the portaudio library is indeed used by professional software. All the software listed in the title of this post qualifies as pro-audio software. I think the issue here is that portaudio is trying and failing to "ping" or maybe apply defaults to Scope ASIO (which it cannot), and is not handling the error that the Scope ASIO driver raises with that attempt.
Portaudio apps work fine with a Focusrite Scarlett ASIO driver, and Motu ASIO driver... There is something in the implementation of the ASIO standard that the Scope ASIO driver is not conforming to the API spec, and the portaudio library is crapping out in some bad / inappropriate (read: crashy!) way as a result. Other apps do not have this problem, so portaudio needs to gracefully handle that error... Other apps - Ableton, Cubase, Reason, Reaper, etc. - must handle that condition appropriately...
I will see how I get on with compiling portaudio.dll. It is open-source after all - if I have a chance to test portaudio scanning my system for Audio endpoints, I should be able to find the bug, and if I find a fix for the bug, I may then look at submitting it to the portaudio trunk..... Would most likely need to be pushed out as some kinda rebuild patch for affected apps tho - dunno if these apps just dynamically link to the off-the-shelf portaudio.dll, or if they have themselves included portaudio source code in their app, and customised it a bit themselves, which would be harder to get released across the dev cycles across multiple app vendors....
Anyway, should I have any progress, I will let ye know.
Not because it is easy, but because it is hard...
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
certain things Scope cannot comply with. it's not a soundcard, although it can fill that function.
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
Yeah I've found it challenging to get Mixbus running on XITE ASIO win 8 x64.
Even on thier latest recent updates.
Even on thier latest recent updates.
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
Eanna! I wish you great success in your recompile! Thanks for taking the "bull" by the horns! 
"I’ve come to the conclusion that synths are like potatoes, they’re no good raw—you’ve got to cook ‘em, and I cooked these sounds for months before I got them to the point where they sounded musical to me." Lyle Mays
Re: Portaudio ASIO apps - Melodyne, Harrison Mixbus, Bitwig,
Nice one Ronnie.
And thanks for confirming Mixbus issues Dante.
Found this too:
http://www.sibelius.com/cgi-bin/helpcen ... 3&&guest=1
More evidence...
Yeah been thinking about it since - Portaudio bridges apps with all common driver types - MME, WASAPI, WDM, and ASIO. It may not necessarily be the ASIO channel at fault here, but my hunch is that it is an ASIO thing. Quite sure you can instruct Portaudio to search for Devices per Driver Type, so I'll be able to narrow it down.
Also, I guess there are two levels of 'fix' here.
At the mo, portaudio is crashing - the apps that use it cannot start. A 'workaround' fix would be to detect whatever issue is going on in the portaudio source, and to remove the offending ASIO device (Scope in this case) from the list of available devices - while that means Scope ASIO wouldn't be available to those apps, it is better than the app not starting at all. Something like ReaRoute or Bidule could be used to route ASIO into Scope I guess (Bidule itself uses Portaudio I believe!). A 'full fix' would be to resolve the issue outright, maintaining Scope ASIO support in the apps... I'll gun for the latter.
I'll be trying the various flavours of ASIO device in Scope Projects too... and hopefully, see what effect those additions and removals have on the Registry too - may be interesting - never quite got how swapping between projects with different ASIO devices worked at the System level.
Gonna leave my Scope installation alone to start with too... since it definitely is broken for me at the mo.
Fair few moving parts in this, but the portaudio source looks lovely, well commented etc. And, I have a testbed where I expect to be able to replicate this easily on my own PC - which is cool.
Cheers, Eanna
And thanks for confirming Mixbus issues Dante.
Found this too:
http://www.sibelius.com/cgi-bin/helpcen ... 3&&guest=1
More evidence...
Yeah been thinking about it since - Portaudio bridges apps with all common driver types - MME, WASAPI, WDM, and ASIO. It may not necessarily be the ASIO channel at fault here, but my hunch is that it is an ASIO thing. Quite sure you can instruct Portaudio to search for Devices per Driver Type, so I'll be able to narrow it down.
Also, I guess there are two levels of 'fix' here.
At the mo, portaudio is crashing - the apps that use it cannot start. A 'workaround' fix would be to detect whatever issue is going on in the portaudio source, and to remove the offending ASIO device (Scope in this case) from the list of available devices - while that means Scope ASIO wouldn't be available to those apps, it is better than the app not starting at all. Something like ReaRoute or Bidule could be used to route ASIO into Scope I guess (Bidule itself uses Portaudio I believe!). A 'full fix' would be to resolve the issue outright, maintaining Scope ASIO support in the apps... I'll gun for the latter.
I'll be trying the various flavours of ASIO device in Scope Projects too... and hopefully, see what effect those additions and removals have on the Registry too - may be interesting - never quite got how swapping between projects with different ASIO devices worked at the System level.
Gonna leave my Scope installation alone to start with too... since it definitely is broken for me at the mo.
Fair few moving parts in this, but the portaudio source looks lovely, well commented etc. And, I have a testbed where I expect to be able to replicate this easily on my own PC - which is cool.
Cheers, Eanna
Not because it is easy, but because it is hard...