PlanetZ forums - scopeusers.com

Operating system version: Win 7 32bit

Scope Hardware: Scope 7 running off 3 x Scope Pro PCI cards

Ulli settings: 3ms

Sample Rate: 48 kHz

Plug-in (if the bug is plug-in related): EDS8i.dev (EDS 8i Drum machine)

Type of bug/error message: No sound when device is first loaded into the routing window even when the main Volume knob is at max volume position. Moving the main Volume knob a little does then make the device produce sound.

If the device is saved within a project then it does produce sound output without needing to first move the volume knob, so this bug seems to only occur when first loading the device into a new project.

A small bug and certainly not a real issue, but a bug nonetheless, so if anyone can reproduce this and verify it isn't just happening on my setup, that would be useful.


Is this the only place to report bugs, or is there a more official list?. Thanks for any info.

I had this issue with scope 5, 5.1 and 7, on Win7 32 and Win8 64: when using Arpeg but bypassing it or keeping it stopped, the notes I hit on my synth have a very short life, no sustain, even though I keep them pressed. They just die.. Because of that I need to remove arpeg from the chain from time to time when I am not using it.

This is related to incorrect timing issues with various devices that use a sequencer or any kind of external midi clock, and I have only tried this on Scope 7 PCI on 32bit. I dont have Scope on a 64bit OS yet, and haven't tried this on XITE, so hopefully some others can try this out and report back to see if this works for them on those setups.

After spending some time today trying to find the cause of the issue I have had with several devices that have sequencers which all seem to have wacked out timing, by a process of elimination I have found that, at least in my case here, the culprit is the DSP file, TIMECLK3.dsp

When I upgraded to Scope 7, before I uninstalled Scope PCIE 5.1 I first made a backup of the Scope PCI folder using winrar to archive it and all its subfolders. I then uninstalled Scope 5.1 which removed all the files that were installed with Scope 5.1. This left any third party files in their respective folders, and after making another backup copy of the Scope PCI folder with just these third party files and folders, I installed Scope 7 which placed all the new files into their respective folders. I didnt copy any files back over from the old Scope 5.1 backup as I seem to recall reading somewhere here that this might mess up the new Scope 7 install.

In Scope 7 I found that many devices which use a sequencer or midi clock were not working when switched to External clock, so I thought I would try and find where the issue was.

I used a utility program called WinMerge to compare the dsp files from Scope 5.1 and Scope 7, and after taking into account any third party dsps, I found that 173 files have been changed, nearly all are .dsp files but 2 are .ol files and then there is 1 file called dsp.idx .

So by copying a certain amount over from Scope 5.1 archive, then testing the external midi clock on several devices, then copying back the originals if they made no difference, I eventually came to TIMECLK3.dsp, and by using the older file from Scope 5.1 DSP folderthis seems to first of all show the correct external midi timing in the midi timing display window on all the various devices I have tested so far, and more importatnly it corrects the midi clock timing on those devices

So far it seems to have corrected the midi clock display when set to external clock such as in SB404, It has also fixed the midi seq timing with Neutron Sonic Attack, Mattomat, SpaceF LBH VIII, Solaris, and other devices that can use external midi clock, such as the Modular patch 808 Groover, etc.

While this is not a fix in itself, but hopefully it is a workaround that will help others until SC can sort this out, so any feedback would be useful. I will post this up on the Scope bug report list.

So basically, make a backup of the newer dsp file TIMECLK3.dsp installed with Scope 7 and replace it with the one from Scope 5.1.

Which brings me to a question about these 173 files in the DSP folder that have been updated. Should I have just copied all those older dsp files back over the new Scope 7 install after but I dont want to do that wIthout seeing what other users have done when they originally updated to Scope 7. Also I can make a list of those files if anyone else is interested, but it would be useful if someone could do a comparison as well and see if they come out at the same figure. I havent looked at any other folders to check the differences there, but might do that just out of curiosity

Finally if anyone needs a copy of that dsp file from Scope 5.1 let me know.

Cheers

=======================================

My setup is;

Operating system version: Win 7 32bit

Scope Hardware: Scope 7 running off 3 x Scope Pro PCI cards

Ulli settings: 3ms

Sample Rate: 48 kHz

Reported now on Lean Testing bug report list. Doesnt seem to be much activity on that site though, and seems to be no way to post a comment on other reported bugs.

you would be better served just writing in to support with your findings. nobody here or on the testing site can do anything about it anyway. the guys who were running the test site and reportuing to SC, are long since over doing that, sorry, but it wasn't their job, so they can quit when they wish to.

generally, you should NOT overwrite newer files with old. if the old file works and works better, then that is something for SC to know, and of course, using the old file makes sense then.

Ok thanks, I'll email support as well. Yes that lean testing site seems a bit pointless really then. At least reporting a possible bug here as well as sending to support means other users can first confirm if it also happens on their setup or if it is not an issue with them, as I guess the devs have enough on their hands without bug reports coming through that are in fact user error or incorrect setup. Anyway, cheers.

yes.

Not really a bug but I have noticed that when I install a new release of Pro Tools and so HD ASIO driver from PT, my system becomes unstable , I have to uninstall the Pro Tools HD ASIO drivers (which are not required for Vanilla version) there is certainly a conflict with the ASIO scope in my opinion but I don't know why ...

Actually I ask to myself if it's not the v7 scope which is very unstable with Cubase (9.5) because it freezes Cubase very often ... even I removed the HD PT ASIO ...

not here....

gary afaik holger is still using the bug tracker system, maybe check with him before deleting.

after the initial setup there that i did it doesn't really need me too much, users can log bugs and holger can edit there.

great!

i wasn't in any hurry to delete anything.

anyways the only thing on my side that changed is that fernando and i are taking a break together, we are still friends and things calm down naturally so never say never on anything in the future i am still alive and will do anything needed in terms of maintaining the tracker if/when needed.

faxinadu wrote: ↑Fri Mar 09, 2018 2:14 am anyways the only thing on my side that changed is that fernando and i are taking a break together, we are still friends and things calm down naturally so never say never on anything in the future i am still alive and will do anything needed in terms of maintaining the tracker if/when needed.

I don’t know where you get your energy from. It’s quite amazing, your relentless. It’s almost too much. You always seem to have something cooking. If you were a chef no one in the world would go hungry, infact everyone would be obese.

Liquid EDGE wrote: ↑Fri Mar 09, 2018 2:59 am

faxinadu wrote: ↑Fri Mar 09, 2018 2:14 am anyways the only thing on my side that changed is that fernando and i are taking a break together, we are still friends and things calm down naturally so never say never on anything in the future i am still alive and will do anything needed in terms of maintaining the tracker if/when needed.

I don’t know where you get your energy from. It’s quite amazing, your relentless. It’s almost too much. You always seem to have something cooking. If you were a chef no one in the world would go hungry, infact everyone would be obese.

hahahaha good question <3

I have just reinstalled Scope 7 for both PCI and for XITE on Windows 7 64bit , and when I load a device that uses Midi Clock input, it reports an incorrect midi clock timing in the display when set to use external midi clock. I previously installed Scope 7 on Windows 7 32bit and this had the same issue, which I was able to correct by replacing the dsp file called TIMECLK3.dsp with the one from Scope 5.1 and I reported this on the thread on 27 Jan.

If anyone can confirm this is happening on their devices when using external midi clock, I would appreciate it. Thanks. For example try loading up SB404 and set to trigger from external clock. The timing does seem to be ok, but the display is incorrect. But when I replace that dsp file it reports correct timing on display. Other devices also.

Hello,

Just realize I have the same problem trying to sync my scope’s to an external midi clock.
I Just replace the dip as you said and now it works.
I check a bit more to see if there is no side effect.
let you know if I found any.

Cheers

I have to add the following bug in Scope 7 with Xite on Win7:

Loading a project where some device is not found automatically.
The find window pops up.
Now I press "options" and I am doomed !!

The whole scope-window is frozen and every mouseclick moves the complete window.
I found no other way than taskmanager to get scope working again.
please fix.

just use browse to find the proper location.

it's because you are loading an old project that had a different directory.

I found dragging a delay into the main scope page crashed it. Loading as an insert worked fine. I will check other ones tomorrow.