Beiträge von thetechnobear

Doh, finally got everything connected and the problem remains!

Mac -> Virus Control -> USB -> Virus TI
Virus TI -> SPDIF (out)-> Saffire Focusrite pro 14

Saffire is set to Internal Clock 48khz
TI set to Audio Clock 48khz
Mac and DAW set to use Saffire at 48khz

Other VSTs played from Mac to Saffire - Fine
Other apps can play thru at 48 to saffire - Fine

Virus TI - played via Virus Control - SPDIF (out1) - distorted

Virus TI - with no DAW, still plugged into USB - distorted

Unplug USB, Virus TI is fine

Or
----
keep USB plugged in - switch to 44 Khz - all is fine.

As far as I can see, it seems like it doesn't like to be connected via the USB and SPDIF as well,
is it for some reason getting a clock from USB and SPDIF that differ?

Also, unrelated if i plug SPDIF IN, then I get 'Illegal clock rate" - any ideas?

thoughts, I cannot find a solution... Id like to have the USB left plugged in for VC, and also the SPDIF for an FX loop.
(id also prefer to have TI as slave not as master for clock, just in case it happens not to be turned on when Im using other synths etc)

Can we broaden this slightly... is anyone using a TI with Mavericks - OS X 10.9 in anyway yet?

I think specifically... do the following still work?
a) USB Midi
b) Virus as a sound card
c) Virus Control.

I think (c) would need to be answered with relation to which DAW it was tested with

mclaulau, as you saying (b) does not work? or with virus control - if so which DAW?

select an atomizer preset , and take a look at it settings.

similarly for an fx unit, select the --input-- patch ... you may need to change between static and dynamic inputs, depending on your input source

Hi,
Im using my TI with an audio interface, where I hook up the output of SPDIF (Mirror of OUT1) , OUT2 and OUT3.
all ok, but in standalone - single patch mode, id like to be able to choose between SPDIF (OUT1) or and analogue outputs (2 or 3),

as I quite like the sound that comes from the analogue ports, but when using fx i like to go thru the spdif in/out.

(i dont have spare inputs to connect the analogue out 1 unfortunately, and id prefer to control from TI side anyway, rather than mixer)

Is this possible?

(I can do in Mutli mode, sequence mode, or VC and you can select the surround sound output, so seems a bit wierd you cannot select the output for single)

Cheers
Mark

ok, ignore this... it seems to be somehow something to do with when the TI is connected to the my Mac via USB, its is reverting to 44k, but the audio interface is saying 48k
im guessing this may be sorted out by telling my mac to use the audio interface, hopefully that will push it to 48k

still a bit unsure why im getting the glitching when i tell my app/soundcard on mac to do 48k

Hi,

Ive just got a focusrite pro 14 and connected it to my TI via SPDIF, the AI is set to be the clock sync @48khz, and the TI is set to Auto (i.e. should be slave) - so far so good, but I get distortion ( almost a high pitch ringing)
If I try the analog outs, no problem - no distortion.

As this the focusrite was new, I thought Id take the focusrite out the equation,
so disconnected it, and instead connected to the TI via VC over USB, and set my app to use 48khz - same distortion.
if i set it to 44khz, the distortion was gone (which is why ive not noticed before, as i usually run at 44k)

Ive tried a few patches (and its in the factory patches e.g. E-Grand)

any ideas, do others use 48khz?

Thanks
Mark

TI Keyboard mk1, 5.0.3

+1 I found the Virus videos really useful.
Anakeys and the new effects would be particular useful, and as batman said something about what kinds of usage you can use the wavetables provided for.

heres how I got it to work in Live 9.
a) Make sure you are not using TI as sound card
b) Create a Virus TI track
c) in VC set Virus to 3/1 (you need 1 input)
d) on Virus select a Vocoder preset (easiest to get started!) e.g. VocoPad XM
e) press I/O on live
f) on audio track that you wish to use as source, change "Audio To" to Virus TI track

then play your audio track (and keep it looping) , and then play chords on your Virus.

from there of course you can create your own presets, and play with vocoder settings.

plug in some headphones into the back , output LEFT. then in VC, change output of part (or parts if many) to output 1 (or direct monitoring)
then do what you have been doing before to test

the reason for trying this, is so you know if the snow is ceasing to generate any sound, or if its just communication of audio back over USB to virus control.

... Im sure access will get back to you pretty quickly, and will be able to quickly tell if they think its a hardware (dsp) issue or not.

good luck, hope it gets resolved quickly.

that doesn't sound good... as note stealing would just be the oldest sound.
does the same happen on analogue/headphone output?

if it doesnt, then i guess it could be an issue over the USB cable, causing issues in VC.

but if it also stops over analogue/headphone output, then that can't be the issue, unless the virus thinks all notes have stopped.

does the sound turn off instantly... or are the releases respected...
if its instant, again sounds like virus is halting...

if its happening on presets as well, Id be firing off an email to Access support,
actually, Id do that anyway, giving them details of your snow, problem and setup and see what they think.

ah, ok, so you are only getting this whitenoise with some specific patches...
you might be getting a 'lfo' effect (phasing) from detuing, either of oscillators or the unison - try altering the detune amount, if its this, then the amount of detune will affect the phases, i.e. rate will alter.

midi panic, or panic... should be on the control panel ... (it is on a TI keyboard, not sure about snow... on keyboard, you have to press 2 keys at same time mono+sync i think). also your daw may be able to send it too. this will turn all notes off, so will let you know if your TI doesnt think its been sent a note off midi message.
this can happen if you send data too fast to the TI... happens with me with my controller (an eigenharp) - i have to turn on decimation to reduce data rate, i don't think it should happen with a DAW/normal midi keyboard though.

Hypersaws, with many saws, layered and unison.... im not sure how many notes you are going to get on a snow like this... it has one DSP, and this sounds like a very complex sound - perhaps overloading? if you simplify a bit (reduce unison, less saws etc) , do you still get the same issues?

when you say sound turns off... all sound? or just you start to lose previous notes? ... i.e. note stealing? (quite likely from the hints about your patch given here)
when this happens if you change to a preset, does it still not work?

You need to supply more details of your setup.

could it be mains interference rather than an LFO?
( perhaps try away from other devices, different location )
Do you get but through analogue outs and headphones?

Try another USB cable anyway, though whitenoise is unlikely from a digital cable,
More likely generated on virus , hence important to check other outs.

What do you mean by hanging? Notes left on?
Can they be stopped with midi panic?
Or is it really completely locked up?
Does restarting VC help?
Does disconnecting USB help?

Hanging I'd have thought unlikely to be related to noise,
unless you have some serious electromagnetic interference going on

Have you tried a reset of virus ?

cool, that was kind of my assumption.
presumably its basically, shifts the voices of a part, to avoid note stealing on that part IF...it wouldn't 'obviously' cause note stealing on the other DSP.
this strategy works quite well with part priority.

I assume that the once part 1 shifts to DSP 2, it stays there, unless DSP 2 later under high load, and then there is 'space' to move it back to DSP 1.

In practice (with a few parts) as you say this would all become quite dynamic, as parts are moved around depending upon current free load on DSPs.
... which is cool, means the DSPs are being utilised well :o)

thanks for getting back to me,
its really good to hear that the virus is using dynamic allocation, somethings id assumed and hoped was the case

the only thing i don't understand, is that i only had 2 parts on part 1 & 2... since the note was stolen it must have been on the same DSP
... no other parts were bring voiced, so why would part 1 be shifted to part 2 dsp ( or vica versa).
i could understand this IF part 1 used all of the its dsp resources, and the new voices for part 1 were added to part 2 dsp , ie it wasnt moved totally, but just moved over new voices to allow more notes for part 1... this would be reasonable since, then if it used up ll resources on the 2nd dsp, part 1 would likely be stolen as its note had been down longest.
( if this is the case this implies the virus is allocating ( or reallocating) at voice level rather than the whole part - no?)

as i mentioned in my earlier post, part priority does come into play and prevent the steal - unsure if it stops the allocation to the 2nd dsp, or if its just steal from the lower priority part on that same dsp (once its been pushed over)

thoughts?

Why not use VC and midi over USB, but use analogue outputs via your AI
You get the benefits of the UI but reduce USB load ( as Audio is main culprit )
I'm sure you have thought of this, but interested if this doesn't solve the problem or if you have other reasons.

how are your outputs setup?
are you outputting to usb 1+2 , or out 1+2 via the your Focusrite Scarlett 18i8.
or do you get the same result on both? i would try both see, if you get a different result.
( generally though if you have a usb AI then it must be on a different usb bus to virus and id avoid using usb audio on the virus)

are you just using one patch on midi 1 ?
, ( i assume since your using VC you are not putting local keyboard on)

I dont know about the Virus A, but I assume you have tried different syses/midi files? (ones produced by the your Virus A for example) ..
. perhaps the file your using, really does have a checksum error... or is at least incompatible with something along the line (Virus, SysEx librarian) ...
are you able to transfer anything at all? also, Id assume you have tried replacement midi and usb leads?

Load... well this will be quite complex, but I think can be simply thought of as, what creates work for the DSP.
a) to start with you have number of notes presents... or to me more specific voices - obvious unison increases this.
b) then its how long does the note last ... this is from note on, to the time the last bit of sound is present (if you have 0 release, and no delays etc, then its when you release the key, but adding delay ,release,reverb all extend this time)... actually, if you think about it, this is really just an extension of (a)
c) processing required to produce the sound... here we have things like number of oscillators, type (e.g. hypersaws use more processing power), fx (distortion doesnt increase (b), but it still takes power)
in my example, really i went for a pad, so hits (c), but keeping the notes down, due to sustain hits (b)

good that you reproduced, shows i didn't just do something strange :o)

but, its back to access... if odd parts are to DSP 1, and even parts are to DSP 2, then why does a note played on an even part ( on DSP 2) caused a note to be stolen from an odd part (on DSP 1)
this makes no sense, and is either a bug or the explanation of voice allocation over DSPs is incomplete.

as I said at the start, even and odd channels being used as an allocation algorithm seems way to simplistic, and lets be clear, it would be very easy to come up and implement a better algorithm for something that is fundamental to the operation of the TI. I find it very hard to believe the talented programmers (and i really believe they are!) at Access would settle on such an approach.
for (an obvious) example distribute the load evenly across the DSPs on a per note basis, i.e. have the same number of voices being voiced on each.
this of course would depend on two things....
a) patch data is available to both DSPs, so both DSPs are capable of playing any patch at any point in time.
b) the scheduler, needs to be know the current DSP load (would be useful to also know patch complexity, to have an idea 'expected' load in near future due to tails)
Even if this was not possible, then a more intelligent algorithm could still be implemented on a patch basis (i.e. that one DSP has to process the same part) , this would be based on two criteria
a) complexity of patch and expected duration (tails)
b) priority
the first could be used to even distribute 'expected' load, then second could be used dedicate first dsp to low priority parts, the second to high priority (or probably better would be to combined with low 'complexity' parts)

id assume in all cases of allocation, the note stealing algorithm must match and must be on a per DSP basis i.e. there is no point in stealing a note, on the DSP that does not have an issue with current load.. you gain nothing.

I might do some more testing,
e.g. do you get more voices in single mode for a particular patch? (i.e is it using both DSP), can we determined other scenarios when note stealing is avoid (like ive shown with priority) ... can we prove that (or not) that note stealing doesn't happen across DSPs , if so this may lead us to a way to better understand DSP voice allocation.

As I say back to Access...
- is there a bit more intelligence to DSP allocation that just the odd/even split, can we get some details?
- In single mode... are you saying only one DSP is used?

Thanks Marc - but now im confused :o)

In the above test, playing notes on part 1, caused notes from part 2 to be stolen...
but your statement contradicts this entirely, since part 2 (being even) should be independent of part 1 (being odd) ... i only had one simple note playing on part 2,
so if it had its own DSP there is no way it should have been curtailed.
yet, it was clear this was happening in VC, and also clear from the audio..

Note:sorry when i said stopped playing the part, this was only because there was one note... as i followed onto to say, it stopped because 'the note was stolen'

what am i missing? I was doing this in ableton live directing the keyboard input to TI track 1 & 2, it was obvious this was being routed correctly, as i could see and hear the 2 parts playing.

if the DSPs are allocated by part (/midi channel) as you say, then the only explanation I have for the above behaviour is that their is a serious bug in the note stealing algorithm, with it not taking into account the DSP allocation of channels... (which i mentioned in my post as a possible but unlikely reason) ... do you think there is such a bug? is access aware of such a bug? perhaps you can attempt to reproduce with my steps above?

can someone else test this to prove im not mad, and mixing something fundamental up :o)

Ok, I was intrigued... and think I have disproved the theory... (unless someone can see a flaw in my test)

Part 1, used GertLead and removed mono (i..e play poly) (complexity 5)
Part 2, used AI2 Pad (complexity 3)

played a high note on Part 2 (channel 2) and kept it down.
played many notes on Part 1 (channel 1) , layed my arm across keyboard to get enough notes :o)

Part 2 stopped playing, i.e note was stolen to handle Part 1.

Out of interest (only) i decide to test priority - I then made part 2 a high priority (default is low), did the same test... and this time Part 2 continued to play.
Finally I set both to high priority, and then had first behaviour, Part 1 stolen as expected, as they are then equal priority (both high in this case, both low in previous case)

This means that the note stealing algorithm treats odd and even parts as equals i.e. same resource
I believe this proves the dual DSP are a shared resource across parts, and the odd/even split of DSPs resources is a myth, or at least not true of OS 5.0.3

Of course, my suspicion is the note stealing algorithm is not as simple as above might suggest ... there could be all sorts of 'interesting' considerations it could take into play. e.g. audibility, usage of FX, tail times etc etc.
The above only proves it can steal across odd/even parts so must consider this shared.
(the only 'flaw' in my argument I can see, is if there was a mismatch in the note stealing algorithm and the DSP algorithm but this is highly unlikely and would be a bug)

It would be cool if someone else could verify my above test (or similar) , as i think its pretty important to squash this myth... if we dont get confirmation from Marc/Access

Sorry, I know it doesnt help your situation UltimateOutsider ... as im not sure how this affects your problem.

EDIT:
just did another interesting test with unison... it seems it will steal notes out of a unison first which is quite cool.
i.e. same test as above but changed part 2 to use twin unison, and carefully introduced notes in part 1, and you could hear part 2, first loose on voice in the unison.
im guessing it probably thins all voices first, and then only cuts all notes if absolutely necessary ... though its quite hard to hear (which is guess is the point ;o)
(also be careful, if you up the relative priority, again it will not steal the unison voices either... be nice if that was an 'option')

conditions of test:
5.0.3, TI (1) Keyboard, VCC but using direct audio output (to avoid issues with USB audio)
a TI2, would use same algo, but of course may require more notes to reproduce test.
patches were chosen to have long sustain, and to be sufficiently different hear note stealing.