Scope Installer could use an overhaul
Posted: Fri Dec 08, 2017 3:18 pm
Having recently set up a dual boot to Windows 10, installing Scope 7 fresh and getting 'timeout waiting for acknowledge from dsp 6 (communication not stalled)' error on Scope 7 startup, I found a workaround.
That is, I copied the SCOPE folder from my Win8 partition, which was Scope 5. with Scope7 installed over the top - to my Win 10 partition. It worked - got rid of the error, but I lost the device menu on the RoutingWindow. I then ran the Scope 7 installer again and now the device menu is re-instated. All works well now, Scope 7 x64 on Win 10. Great.
Seems to me that one area of focus could be the installer, where this could eliminate a LOT of support issues if done good. Heres what I'm thinking the attributes of a new installer would be:
. Base scope components would be separated from 3rd party products. This way, it would be possible for the installer to blow away and re-install a fresh base Scope and stock devices, without touching the 3rd party stuff. And 3rd party stuff should be able to use the installer just to install their own devices (also without touching the base Scope structure)..
. The 'menu constructor' part of the installer should be able to be run anytime independent of a full install. The menu constructor would create a single combined menu consisting of S|C devices and 3rd party devices - even though third party stuff would be a separate subfolder.
. The menu structure and a manifest of all devices would be stored in an XML file.
. 3rd party's should include an XML manifest of all files for that given device (.dev, .dll, .dsp etc) which would be merged in with the main XML manifest.
. 3rd party device manifest XML's could be written any time - eg by support or anyone here.
. A scanner could scan the current installation to rebuild the manifest.
Im thinking some of these (somewhat rough) ideas could be improved or evolved and emliminate some of the setup issues that come from having to manually merge or reinstall 3rd party devices after a fresh install of Scope. There seems to be no real formalised way of doing this at the moment.
Thoughts ?
That is, I copied the SCOPE folder from my Win8 partition, which was Scope 5. with Scope7 installed over the top - to my Win 10 partition. It worked - got rid of the error, but I lost the device menu on the RoutingWindow. I then ran the Scope 7 installer again and now the device menu is re-instated. All works well now, Scope 7 x64 on Win 10. Great.
Seems to me that one area of focus could be the installer, where this could eliminate a LOT of support issues if done good. Heres what I'm thinking the attributes of a new installer would be:
. Base scope components would be separated from 3rd party products. This way, it would be possible for the installer to blow away and re-install a fresh base Scope and stock devices, without touching the 3rd party stuff. And 3rd party stuff should be able to use the installer just to install their own devices (also without touching the base Scope structure)..
. The 'menu constructor' part of the installer should be able to be run anytime independent of a full install. The menu constructor would create a single combined menu consisting of S|C devices and 3rd party devices - even though third party stuff would be a separate subfolder.
. The menu structure and a manifest of all devices would be stored in an XML file.
. 3rd party's should include an XML manifest of all files for that given device (.dev, .dll, .dsp etc) which would be merged in with the main XML manifest.
. 3rd party device manifest XML's could be written any time - eg by support or anyone here.
. A scanner could scan the current installation to rebuild the manifest.
Im thinking some of these (somewhat rough) ideas could be improved or evolved and emliminate some of the setup issues that come from having to manually merge or reinstall 3rd party devices after a fresh install of Scope. There seems to be no real formalised way of doing this at the moment.
Thoughts ?