Luna 2496 I/O box woes

[st1]

Hello,

I am trying to test whether a Luna 2496 I/O box is still working.
It has not been connected to anything for years, so I am trying to see if it still works.
I dug out a Creamware machine from storage, and hooked the box up to the Z-Link port on a Luna board.
Everything starts up fine.
The luna board plays fine through the on-board audio out.

But when I try adding "Z-Link A Dest", I get an assertation failed dialog box with the text ".\system.cpp (3565): fix == -1 || fix == brd".
The mixer now becomes unresponsive, but sounds is still flowing through the DSPs (but I can't re-route anything).
SCOPE needs restarting.

I have tried two different firewire cables (one which is the original), and two different Luna boards.
Same behaviour.

When I turn on the computer, the LEDs flash briefly in the 2496, so there is power to the unit.
But otherwise it seems inert.

I am running SCOPE v7 on the host (HP workstation), with a Pulsar II board carrying the license.
The Pulsar II and the Luna are seen fine by SCOPE, and work as could be expected (DSP load, outputs etc).
But trying to use the expansion box makes the system unstable.

So...
Question: Does SCOPE v7 still support Luna 2496 I/O box?
Question: Is there something else I need to do to enable the Luna 2496 in v7?

st1

[astroman]

Disconnect the Luna box and then route some mixer IO to the Z-Link source destination.
(to verify if Z-Link is supported at all)
Refine by using another mixer with the same procedure.
If the error remains, at least you know the Luna box probably isn‘t the main reason.
Did you check sample rate/clock settings ?
Move the Luna to another slot might help... kind of „wake up system settings“.

best if luck, Tom

[garyb]

it should work.

is the zlink "led" lit in the samplerate window when the Luna box is connected?

[st1]

Disconnect the Luna box and then route some mixer IO to the Z-Link source destination.
(to verify if Z-Link is supported at all)

Works fine, no errors.

Refine by using another mixer with the same procedure.
If the error remains, at least you know the Luna box probably isn‘t the main reason.

Error pops up with box connected, and "Hardware IOs->Luna->Z Link A Dest" or "Hardware IOs->Luna->Z Link A Source" is added the first time.
After clicking assert box away, the error isn't shown again, I can add/remove Z-Link Source and Dest.
But there is still no output/input via the box.
And no lights on the box.
And the mixer window is hung (althoug sound still comes through the Luna Analog output).

Did you check sample rate/clock settings ?

Tried 44.1 and 96 KHz, no difference.

Move the Luna to another slot might help... kind of „wake up system settings“.

Will try, but requires a little work due to physical issues with motherboard and connector placement.
I will probably try with a different machine/Luna board to see if that makes a difference.

is the zlink "led" lit in the samplerate window when the Luna box is connected?

Yes. (And not lit when box disconnected.)

[garyb]

the error indicates that the box has a problem.
if it happens with a NEW hdmi cable, the last ditch try is to rerun the Scope installer(over the top). that would fix a bad file.

otherwise, i think the Luna box may be broken.

[st1]

if it happens with a NEW hdmi cable, the last ditch try is to rerun the Scope installer(over the top). that would fix a bad file.

Tried two different FireWire cables, same result.
They are not new, but they did work last time used.

otherwise, i think the Luna box may be broken.

Understood.
To try this out, I fetched the other Luna 2496 box I have from storage.
Unfortunately, the response is the same.
I will try a different host now, just to check if that could be source of problems.
(This might also highlight corrupt files, although I must confess that corrupt files is not something that pops up very much these days in modern operating systems...)

[astroman]

Another host is a good idea...
Btw „corrupted files“ doesn‘t necessarily mean that file content is damaged.
Often messed dependencies in the Windows subsystems can have a similar effect.

During the years I‘ve (occasionally) seen some bizarre Scope errors that more or less self-healed, often by a new installation, switching slots or changing the PC hardware.
To be fair that isn‘t an exclusive Microsoft feature... old Macs were great in faking dead hardware which could easily be resurrected if one knew the „trick“.

[st1]

Moved a Luna to a different machine (DELL T3500), and connected everything.
Exactly same behaviour, unfortunately:

- 2496 box LEDs flashes when computer boots.
- Z-Link A is on in the samplerate Settings window.
- Audio plays fine over the Luna D/A.
- Opening Luna Z-Link Destination brings the same assert() error.
- Afterwards SCOPE behaves erratically - sounds continues as it was, but mixer windows hang, and no sound from 2496 box.
- Re-starting SCOPE brings normality.

(In case you don't know, asserts are often used in C++ to sanity check return codes and state variables in situation where a wrong value would be unlikely, and continuing operation unpredictable. It is not meant for "fixable user errors". I guess this is an "oops, something is very wrong" situation.)

My question is still:
> Is the Luna 2496 compatible with both 64-bit Scope 7?

By now, I am inclined to think no...

My gut feeling is that the 2496 works (digitally, at least), and should probably play well earlier versions of SCOPE.
It could also be a 64-bit/32-bit issue.
But my hunch is that this is a software [edited: "(evolution)"] issue.

[garyb]

yes, the Luna box works.
64bit has nothing to do with Scope, only how Scope connects to Windows. Scope is actually the gui and controls for the dsps, Windows is not really involved.

in any case, Windows is not involved with the Z-Link connection in any way.

[st1]

64bit has nothing to do with Scope, only how Scope connects to Windows. Scope is actually the gui and controls for the dsps, Windows is not really involved.

Ok, but then I am confused.
Why did the STS-modules stop working (well) on 64-bit versions of SCOPE?
Was this a deliberate decision from SC?

in any case, Windows is not involved with the Z-Link connection in any way.

No, I agree.
But the SCOPE software platform is, and if there are differences on how it works in 32- and 64-bit land, then there could be differences in how it handles outboard Z-link'ed gear...

So SCOPE is the most likely cause of the problem.
Why else do I get an assertion failure in SCOPE when I try out either of the 2496 boxes?
I agree with you, it is definitely not a Windows problem - but where do I look now?

[sunmachine]

Maybe you can get a key for SCOPE 5.1 from S|C to check if that makes a difference.

[garyb]

the STS problem is because STS uses system memory. there, 64bit makes a difference. but in the Z-Link case, Window has zero involvement.

Scope itself is a 32bit application.

[Bud Weiser]

the STS problem is because STS uses system memory. there, 64bit makes a difference. but in the Z-Link case, Window has zero involvement.

Scope itself is a 32bit application.

At least on XITE-1,- it should be possible upgrading STS 1000, 2000 & 3000 to use local RAM.
The original AKAI S-1000, S-1100 and 3000 series samplers always used 2 - 32MB of RAM max.

Isn´t it, a single of XITE´s 333MHz SHARC DSP chips offers 32MB of currently unused RAM ?



Bud

[garyb]

could be...

[st1]

Maybe you can get a key for SCOPE 5.1 from S|C to check if that makes a difference.

That's certainly route.
Thankfully, I have a 5.1 key for Pulsar board.
But I am running out of spare machines with PCI slots.
All my machines are v7 now, and unstalling v7, installing v5.1, then re-establishing v7 that would mean "unstabilising" a system.
Alternative is getting and putting a new HDD disks in one of them, then installing windows and then older SCOPE version just to test the box works. And then revert the whole thing, as I will not be using the 2496 for anything at the moment.
(I am selling it, just wanted to check if it still worked.)

But thanks for the suggestion.

[st1]

the STS problem is because STS uses system memory. there, 64bit makes a difference. but in the Z-Link case, Window has zero involvement.

Scope itself is a 32bit application.

Ah - that explains things.

thx