But that is the whole point why i wrote the whole story about allocation and optimizing. There are flags to be set and design constructions to be made in order to use or tell scope about how to allocate or optimize. The software on itself ofcourse does not know automatically what is best if you dont set boundaries or guidelines. One has to build that into a device. Simple example...there are some ms decoders and encoders running free here for the platform. Ms techniques rise and especially fall with phasecoherency. So if you use some plugin on the mid part and another different plugin on the side part thing are bound to go wrong! Mid and side should be kept absolutely phaselocked. There cannot be a 1 sample difference between them. How should scope know that all this should be kept phasecoherent? It cant. So if the encoder works on chip 1 and plugin for m on chip 2 and plugin for s on chip 1 of pci board 2 ..and the decoder splits itself over chip 3 and 4 of any board a lot delaying is introduced. Well...its in the sample range...but for the m it is different than for the s. You can solve this by using delays yes...but next time you load the project or introduce a heavy plugin which will trigger the scope optimisation the dsp assigment will be different and adjustments to the delays have to be made. These are exactly the things one should consider when developing or screwing around.
So still...it is to the developer to make sure scope can unleash it potential. If you say thing got better with v5 that would simply mean that the plugins were rearranged or redeveloped with these considerations in mind. Is this making any sense?
