Beiträge von thetechnobear

definitely let us know how you get on. thanks
I'm in a similar positions, with quite a few usb devices that I use for music production

btw, did you get a KTU10 (w / eSata) or KTU20 (w/ethernet) ?

sorry, I know this comes up a lot… but id like to create a definitive thread, so I will hopefully add some value here.

Requirement: we need to use a USB hub with multiple transaction translators (MTT), most hubs use a single (STT)

Specific usb hub products:
Plugable usb2-hub-ag7 - http://plugable.com/products/usb2-hub-ag7 (untested, but is MTT)
Manhattan 7-Port USB 2.0 Ultra Hub - http://www.amazon.co.uk/gp/product/B0035LXOPY
(I know there is talk about a belkin 7 port with mtt, but don't know its model number, and if its a current model… or if the replacement still is MTT.)

USB chipsets supporting MTT
Terminus Technology FE1.1s & 2.1 Chipsets
Gensyslogic (a few, not not all, check website for list) - http://www.genesyslogic.com/en/product_list.php?1st=3&2nd=10

USB chipsets NOT supporting MTT - i.e STT. don't buy!
VIA VL812 - http://www.via-labs.com/en/products/vl812/#blkdiagram

if anyones has a hub, they know is MTT then I will list it here, or if you know other chipset which do have MTT
(im not going to list all hubs/chipsets that don't have MTT, ive only listed the VL812 as its pretty common)

sorry, my misunderstanding then ….

my understanding was you said it could not be used as an fx loop
i.e. audio interface(master) -> audio/clock -> virus (slave,spdif) -> audio -> audio interface.

where as now I'm understanding, you meant it more generally:
you cannot have the virus using a slaved spdif clock, if you are going to send the audio output back over spdif
(without resampling the audio, but if you do this, there is no point in sending a clock in the first place… no?)
is this correct?

so when is it useful to have the virus use an external spdif clock input?
(my assumption, and please correct, me as it appears they usually are wrong!)
is that its only useful to use the spdif clock slaved if you are sending an audio signal as input over spdif
AND then are either:
i) sending the output via analogue outputs
ii) sending the output via spdif, but resampling the output on the audio interface.
correct?

sorry, if this is all very clear to you, but i think others like me, just assume you plug the 2 spdif cables in, set it to slave, and it just works… so its useful for us to know this is not the case, and what the correct usage is.
thanks for your patience

Zitat von Marc

if you setup something like master --> Virus (slave) --> another slave device there is no technical reason why it should not work.

ok, this is complicating matters, simply the issue we have is
audio Interface (master) --clock over spdif --> Virus (slave) -> audio output over spdif -> (same) audio interface

with this, we are getting clicking at higher frequency notes, even with a simple sine wave...
clicking that does not occur, with analog outputs or usb output, and we are not clipping the signal.

so why the clicks?

its not just, should it technically/theoretically work... the question is does it work for you?
(again, assuming you don't resample, which negates the use of the audio clock)

yeah, I remembered being told in the loopback scenario i would need to resample. (ie. spdif in -> vir -> spdif out ) e.g. for digital fx loop.

but this is not in loopback, this is soley, spdif output (no spdif audio input) from the virus with the virus using the spdif clock from the audio interface (which obviously comes over spdif input)

are you saying the virus can never use an spdif clock input source, it has to use its own clock?

what i find, odd about this, is when I use USB (which is digital like spdif), the virus is slaved to the host clock, which in my case is also provided by the same audio interface…. (this also works for audio loopback) , so it would appear the virus is quite capable of slaving to an external clock, just not via spdif.

> if you use a pure sine wave on a low volume, you would hear much more, in case there is something to hear
yes you can hear it using a sine wave on osc1, no effects/filter etc... its just a bit harder to hear, and yes its present at low volumes (its not clipping)

perhaps worth saying... I originally notice this on a normal factory patch, in normal play (I think E-Grand HS)... obviously it was quite subtle,
but very annoying (and not something you could record/release!), so i then tried to reproduce it, and make it more pronouced,
so that Access support could reproduce and hear it, and then of course 'eliminate other possible causes'

and why I assign it to a SPDIF sync issue? because even account for output levels (i.e. matching them) , with exactly the same patches, I don't get this when using USB output and I don't get it when using analogue outputs, and also if I change the Virus to SPDIF master again the same patch is also absolutely fine.

there have been other reports of this in the past, and here amused and I, are reporting exactly the same issue... despite completely different hardware.

Were you able to reproduce the clicking using SPDIF, where the virus is the spdif slave? (and you don't do any resampling of the input on your audio interface)
(your words, "I think it just clicks..." seems to imply not, it implies a logical thought process instead of testing it)

please, I know, lots of issues are reported that are due to user error, but surely given we have gone to the effort of a reproducible test case, have multiple users reporting,
... does this not warrant Access spending a few minutes to see if there is a slight chance there may be an issue?

you may be right, it may have nothing to do with the spdif... (though I hope you can see why i think it is, due to details above),
if you test it, I'm sure you will then be able to prove this one way or another, and enlighten us, to how we can prevent the issue arising with spdif, and start using it.

does this sound like a reasonable way for us to work together to find a solution?

Ive tried this test case, and get exactly the same error.
Im using a TI keyboard mk1, with a Focusrite Sappire Pro 14.

(important note: with exactly the same patch, if you route it via the analogue outputs, I do not get the click so it is not a function of the patch/filter etc)

> RME as master as it also sets the midi clock
I assume you mean, for the midi message timestamp (rather than the midi clock msg), and yes that true, and very important to use a stable clock source for, and Id prefer to use the Pro14 for the same reason.
(that and often my TI is not within the setup, and i don't want to have to continually reconfigure this)

i play with it infrequently, (and never get much useful out of it ) but if i remember correctly the input is 'gated', and then the level is changed by the mod wheel.
in reality, every time i use it, i have to go and read the manual again .. which does have the info.

but what happens? it obviously cannot now load the snow plugin as you have deleted it.

to be frank, if its loading the wrong plugin, then thats maschine, not the virus…

perhaps you need to do a rescan of plugins (or whatever its called in maschine)

delete the snow plugin?

yes... its tricky to find on the panel, i remember having to dig for it

but if you press OSC EDIT twice , goto to common page 1/2 and you will find key mode, here you will find hold.

(as you've no doubt found its not on shift + mono , is that a bug?)

in the midi settings, you will find midi clock, set this to sync to external… it should be the default, but perhaps its been changed. also check you are sending midi clock from the 300.
(again this is in the manual)

@marcoIMD, this is a very general thread, your far better creating your own thread and describing exactly what your issues are. - also why not try 5.1.0?
usually, latency and sounds issues are related to your specific setup, so post 'me too' really won't get you a result.
(ive had my fair share of issues with USB and the TI, but none that I couldn't solve... so its not a general issue as some will have you believe, its just not necessarily easy to setup, and many do struggle with it)

@inf7cted, does this click happen on every patch you use, including the init patch? if not then it could be something to do with the patch i.e. more a sound design issue... so might be better posting in the sound design section, perhaps with details of the patch and a sound example. also more description, when you say "virus ti stops in the middle of a sound", this doesn't make much sense... how can be be stopped, and in the middle of the sound? (surely that means its at the end?!)
... if its a patch related issue, then you you would need to check want envelopes and LFOs are doing, perhaps one of those doing something like snapping a filter shut (example only!).
Similarly, phasing, sounds more like a sound design issue ... that or you don't have your audio sync setup correctly e.g. running a 48khz signal into a 44khz, but again you'd need to be far more specific about the issues, and when it occurs, and when it doesnt.

Ive quite some sympathy for Access support, so many people tag on to topics, say 'me too' giving very little information about there setup, what they have tried, when it works, when it doesn't... you need to help them, help you!

hmm, sounds not very healthy.
it would be easy to speculate, but its probably better you contact access support, as Im sure they can help you diagnose the issue, and determine if its hardware or not.

Id concentrate on getting it to work standalone without the computer first, so the computer software is 'out of the picture', also if it 'crashes' standalone, its never going to work properly with the computer.

Personally, I would be tempted to upgrade the OS to 5.1.0 or 5.0.3, as this not only upgrades the software on the computer, but also the firmware on the Virus, and perhaps there was an issue with the firmware version your using.
(sure this might introduce other issues, but if its solves the crashing issue, then you can resolve these other 'less serious' issues with access support)

has this all just started? was it working okay before?

so my 'suggestion' would be upgrade, see if it works standalone, and also start talking to Access support, they are very responsive.

ok, bad (semi) news...

the sleep issues does still seem to exist in some form, I turned on my virus to do some stuff, was happily playing away - then about 5 minutes i decided I needed my Push so turned it on...
poof, Virus Midi device disappeared, so now I have to restart ableton, as its now showing up as Virus Synth #2. (after i do a midi rescan)

can someone else test this, I'm a bit surprised I seem to see it with many (all?) of my USB devices, yet its not a known issue.

thanks, yeah, id guessed it was just a rare oddity… its the first time I've seen it.
so is just removing the power cord enough? ( i didn't need to go to usb update mode?)

btw, another oddity I've noticed (again no real issue)
if i disconnect power from the TI, while it is turned on, when i reconnect and turn the TI, the LCD display is corrupted. (i used to just turn off at the power supply)
so instead before I turn the power off, I always now put the TI in 'standby', then power off.
no real problem, i guess its some kind of power spike issue, but wondered if its common.
(its a TI mk1)

ok, update...
so, the other day when i installed 5.1.0 i got the problem as described above...
but today, I decided to test the Push to see if it made the device disappear after sleep, and it didn't.
so i then tried my other devices... and all was OK!!!

anyway decided to power down the TI, and try one last time...
TI didn't initialise USB midi driver at all, no USB on TI display, midi device in audio/midi app shows disconnected.
checked the console and I can see:

23/10/14 20:14:46,000 kernel[0]: USBF:    170713.724    The IOUSBFamily is having trouble enumerating a USB device that has been plugged in.  It will keep retrying.  (Port 1 of Hub at 0x14000000)
23/10/14 20:14:51,000 kernel[0]: USBF:    170718.152    The IOUSBFamily was not able to enumerate a device.

and further up...

23/10/14 20:09:22,000 kernel[0]: DeviceRequest returns E00002ED
23/10/14 20:09:22,000 kernel[0]: DeviceRequest returns E00002ED
23/10/14 20:09:22,000 kernel[0]: start PGKernelDeviceVirus v3.3.0.b.4 failed. reason:m_pDevice->onServiceStart() failed

doesn't matter if I restart TI, or reinsert USB cable, same issue.

so for some reason, TI will now not initialise (its been working fine on 5.1.0 for days), so adding/removing usb devices must have some how provoked this
... I'm going to try rebooting, see if this 'fixes' it.
UPDATE: ok, so rebooting did NOT fix the issue TI still refused to connect, I then did a 'soft' reset (arp edit, power on) - still nothing. Rescan Midi - still nothing.
I then tried VCC. this could not see TI, so I put it into USB UPDATE MODE, and magically, midi driver loaded, and everything was back to normal!

Unfortunately, for the above, Ive no real idea how this occurred... other than plugging/unplugging usb devices, but thats not going to be 'reproducible',
... will let you know if it happens again (unlikely i think), but at least I know how to fix it, if it does

Sleep issue, Ok, I'll presume it was gremlins after the 5.1.0 install, and was fixed in 5.1.0 (thanks Access ) ... so, I'll stop 'working around it' and let you know if i see it again.

the issue is still in 5.1.0

sequence (assuming mac is on, and virus working fine)
a) turn virus off
b) put mac to sleep, (wait until it really is a sleeping, can take 10-15 seconds)
c) wake mac
d) turn on virus
at this point, virus works fine, midi is connected etc - all good
e) connect another USB device
f) start an app that queries available usb devices (I'm not 100% sure if this step is necessary,but i think so)
bang, Virus Midi device disappears.

Ive got a few USB devices that this happens with, Leap Motion, Eigenharp Pico, Keith McMillan soft step,
(and i think Push as well, need to double check that one)

the 'workaround' is to ensure that the virus is turned on last, so never connect a new USB device when the virus is on. this is a bit of a pain sometimes as you don't always know what you will be using.
if the virus midi device disappears you can bring it back, by doing a midi scan BUT, this can cause problems with quite a few applications, they get confused by the Virus midi device disappearing,
(e.g. Ableton, you end up with Virus Synth , and Virus Synth #2, the former doesn't work, so you need to alter your project to the later… but then can't save it, as next time it will be Virus Synth - arghh!)

Ive checked in the console/logs, and there are no errors reported…

also, I got a new iMac at the end of last year, and the same thing happens with both old and new mac.

its not a big issue, but it would be great to see if you can replicate, and therefore get the devs to take a quick look.

@Marc, this bug is still present in 5.1.0 ... can its priority be raised?

basically seq mode is the same, so if your using the VC you don't need to use multi (or single) mode.

realistically, Access are never going to produce anything else (as much as people can want it!)

but http://www.mysteryislands-music.com is working on something,
theres is also an iPad app (sorry can't remember what its called) , works with ipad2+