running scope 32bit on a 64bit machine

[jhulk]

now

i have been talking to a vsti developer and he has his 32bit coded plugs working in windows 8 64bit

and all his 32bit plugs can have the max 3.5gb memory access for each 32bit plug

so my question is this has any one tried to actually load scope 5.1 32bit on a 64bit machine

as this might help those who use a 64bit machine to use the samplers and full 3.5gb memory allocation just for scope

i dont have a 64bit machine so i cant try

but if it works for 32bit vsti plugs then it could work for the scope 5.1 32bit software

[garyb]

no. it's not the same at all. it will not work properly.

many parts of Scope are 32bit, but the interface with windows must be 64bit.
if 32bit Scope worked in 64bit windows, S|C could have saved 2 years of development.

[jhulk]

windows 8 was not out 2 years ago

thats why i was asking

im happy with scope 5.1 32bit

its just that the new sample osc which is great does not work on 64bit machines

out of memory errors and no poly

and because this vsti developer is running both as he is porting his mdls to 64bit and using the 32bit versions as cross referencing

to see they are performing the same

its just that i have a coded dsp wave scanning osc that im hoping to port with the sdk6

and im hoping that theirs going to be a 32bit version but if scope 6 sdk is going to be just 64bit it means i will need to port my c++ 32bit code to 64bit code before i could implement the atom in scope 6 sdk

[garyb]

not being a programmer and only understanding the function from a theoretical point of veiw, i would offer this explanation.

a vst is not anything even close to a realtime function. if extra latencies are involved in converting between 32 and 64bit operation in calculating a vst plugin, it just takes a little longer. the sequencer's latency compensation kicks in and the user doesn't know the difference.

since Scope is operating NOW, any extra latency wrecks timings. things just won't work correctly in that case.

windows 8 or windows 7 or xp, what happens when 32bit software is run in a 64bit environment remains pretty much the same. the newest os simply has less roadblocks to the process, but the disadvantage of that process remains identical.

[jksuperstar]

I remember reading here someone used Windows 7 professional Virtual PC/XP-Mode to install drivers and editor for their now unsupported NOAH. And that seemed to work ok.

I will be doing a full rebuild of my laptop toward the end of this month (just ordered an mSata SSD for the OS/Programs), and can give XP-mode a try at that time or maybe before then. I am VERY interested in the new modules for modular, and since x64 support is lacking for many things I really would like to use in scope (particularly sequencers and sample based oscillators/devices), I'm willing to take this back-handed route. I don't have a spare x86/32bit license for windows around, so I won't try a dual-boot.

If this does work, I don't mind *if* there's any extra latency over my normal install, as I would be shuffling midi/audio in & out of the host even less since the features I want would be totally inside scope. I don't expect any latency issues though, as the PCIe bus is mapped into memory, so accessing a scope interface card to xite, or accessing memory, shouldn't be *any* different. I probably just need to manage whether the native x64 scope driver is loaded while running XP-mode and the x86/32bit driver.

[garyb]

it's not just a matter of if you don't mind the latency. any latency would be sub-audible, just long enough to throw off system timings.


actually, i encourage you to try. if you get it working, that's great!

[jhulk]

for me its more of the scope sdk6 if its only going to be 64bit

then when i get it im going to have to upgrade my systems to 64bit if i want to code new atoms for scope

6

as with samples for bigger sample sets than 64bit will be needed and new 64bit multisample playback osc will have to be coded

but with bigger host ram and ssd for sample storage with ssd disk streaming

the things im doing with modular in the 32bit realm is amazing but with bigger rams

4-12 multi velocity layers of 1gb multisamples samples for each key

which you need for the round robin fx of analog synths to capture them really well



im just wondering whether i will need to start thinking about the 64bit os if thats the direction of scope 6 sdk is going

[garyb]

for the sdk itself, i don't think that it matters at all. if you need to write script for 64bit windows, it might...

[jksuperstar]

So I've done some homework, and besides hardware virtualization for the processors, Intel and AMD both also provide *hardware* virtualization, also called PCI Passthrough, which allows virtual machines, even 32-bit ones, to directly access hardware (The motherboard remaps IRQs and I/O addressing to the Virtual Machine, which requires features built into not only the processor, but also the chipset). Intel calls it "Vt-d". Microsoft's Virtual PC and Hyper-V doesn't support it (that I could find), but Sun/Oracle's VirtualBox does. And if you install XP in virtual box, then in theory all of this could work.

That is, assuming one has a new enough processor and chipset to provide these features. My Lenovo W520 happens to have both features (chipsets AFTER P67 support Vt-d, and even some early QM67s have a bug regarding Vt-d (I think the famous SATA bug was fixed at the same time)).

So, I'm gonna explore this a bit, and see what happens. I don't see any guarantees that SCOPE 6 will fix any of the features that are currently disabled in scope 5 x64, so this could be worth it for a lot of people in the community. Stay tuned.

[tgstgs]

you compile for a target x86 or x64 win or whatever;
when only using libs this should do the job;
if youre using own functions and objects you must change all pointeraddres types from int32 to int64;
---
on linux you set up a virtualmachine yourself running for exapl. windows at same time;
on windows i use vmware to run 32 bit/ 64 bit windows and 64 bit linux next each other;
dont get me wrong you shouldnt do this for a daw but
for a developingstation its great_

virtual vibes

[jksuperstar]

for me its more of the scope sdk6 if its only going to be 64bit

then when i get it im going to have to upgrade my systems to 64bit if i want to code new atoms for scope 6

Since tgstgs is here, and The Analyzer was developed with SDK6, and it works in both x86 and x64 environments, then I think SDK is still available to both
------------------------------------------------------------------------------------------

Also, UNLUCKILY, it seems Windows 7 DOES NOT support Vt-d/AMD-Vi/IOMMU in it's kernel. That is something that is reserved for Windows SERVER 2008. So a dual boot seems to be the only option for those that currently have an x64 system.

[tgstgs]

yes i have sdk6 for x86 and x64;
-------
Windows 7 DOES NOT support Vt-d/AMD-Vi/IOMMU ????

dont know about this but im working on a win7 64 bit machine having x86 and linux running as virtualmachin at same time with vmware;
you can exactly tell what to mount and how much recources you use for what__
switching from one to the other like you switch applications;
only you cannot use xite in both x86 and x64 the same time; just one after the other
this is much better than a dual boot_
code compile for both targets / test in x86 / switch to x64 test again __
if you dont need any longer you simply delete the folder - gone -

good vibes

[jksuperstar]

Vt-x is supported (processor virtualization), but IOMMU (direct access to hardware like XITE) doesn't seem to be. The usual virtual machines give access to network, USB, and storage, but not directly to graphics card, pic cards, etc.

[jksuperstar]

Maybe I should say: you have xite installed on your VM?!! In XP Mode? Linux?

[tgstgs]

no you are right;
xite installed on host x64 win 7
but accessible from xp or linux yes;
--
you mean its not possible to install xite driver on xp VM right?
thats the point?

didnt try this so far_
but will do_
good vibes