Beiträge von straius

Thanks for the link, I'm not sure if you're trying to link to a search, but the link produces an error. Invalid or it no longer exists.

I a did a search specifically for the Belkin after you mentioned it, but it still returns mostly anecdotal comments from users and not an official recommendation from Access. But based on that, I guess it's the next step.

I had searched the FAQ before posting here as well. Would be nice if they added this info to the FAQ and/or a sticky post for common Q& As

The Snow doesn't get recognized at all if it's connected to a USB 3 port on the intel DX79SR. So I was planning on a USB 2 card unless Access suggested otherwise.

Thanks for the information guys.

Hi,

Is there a recommended USB PCIe card for use in a PC for the Ti series?

Currently I am using the supplied USB cable into a USB 2.0 port without any other devices sharing the internal hub. But I am experiencing inconsistent detection of the snow in Reaper.

Reaper is version: 4.52/x64 rev 749c96

Ti Software is version: 5.0.3

ASIO device is SLL Nucleus: Audio driver version 1.26.0

I had a USB 3.0 PCIe card in the previous PC build dedicated to the Ti Snow, but that same card doesn't play nice with the current PC hardware configuration so I'm looking to purchase a new USB PCIe card. Is there a preferred manufacturer or specific card that Access recommends?

Thanks!

I'll give those another look, but currently I have all of those set to "safe" settings. I don't see anything immediate that would be applying to the snow during mixdown.

It's interesting to me that the only variable that changed in my system was the interface card. With the same settings (and drivers), I was always able to bounce without problems when the Snow was connected to the USB 2.0 PCI card.

But it's possible that changing that just highlighted a different problem I suppose.

Hello!

I am using Windows 7 x64 and Reaper x64 as the DAW host.

The Virus Ti Snow is connected to a PCIe USB 3.0 card (Buffalo Technologies - http://www.amazon.com/gp/produ…ef=oh_o00_s00_i00_details)

There are no other devices sharing the USB Root Hub. The snow is the only connected device.

Operation seems to be normal inside a project minus some beat sync issues I've had with the LFOs (Live button has no effect).

When I render the project, I get an error stating that the midi driver failed and even a reboot will not refresh the Snow. I have to reboot and then plug it into the other port on the PCIe USB card to get windows to "re-acquire" the device.

Previously I had a USB 2.0 PCI card that was running the Virus, but Windows 7 was flaky with that card and detection of the card was intermittent. So I replaced it with this card and I now have consistent operation of the Snow except for this rendering problem.

I tried testing it with "Fullspeed Offline" as I understand the Virus is disabled during mixdown, and I receive the "Midi Driver Failed" error.

I tried a real-time "Online" mixdown and received the same error again.

Are there any known issues with using a USB 3.0 port?

Thanks for any help! Please let me know if there is more information I should supply.

Much appreciated!

Any chance that we could make that work?

It's currently not available for automation.

Wouldn't that eliminate the ease of assigning automation though?

The main benefit I see from select-able MIDI inputs per part would be preserving automation and MIDI data on channels that you have recorded to audio to free up voices.

I suppose you could assign CC control data to parameters in the unit itself? I don't even know if you can do that via the hardware interface.

Which of course disables what I see as the most powerful part of the virus in the first place, the VST control.

It's an edited image Watuse, not in the VST.

Been a few days, can we get any comment from Access?

[Blockierte Grafik: http://www.straiusmusic.com/Access_Snow_MIDI_Input_Request.jpg]

@Crystal

The used market doesn't generate any profit for Access. And I'm fine with less polyphony, no keys and no knobs. If there was nothing but an LCD screen on a box with a USB out... I'd still be fine with the hardware. I'm talking about a modification in how you interface with the snow. Not extra processing power, hardware or other advancements. Improving an existing tool's effectiveness, not it's capabilities. People seem to keep missing that distinction. It's an important one. And one you should care about as a consumer of any of their products.

watuse

The capabilities and limitations aren't comparable between the two units because their architecture is going to be entirely different. Depending on how the instrument is developed it will have entirely different limitations and problems to work around.

I believe that what Marc is saying is that streaming all those audio channels (very data intensive) discreetly would be impossible for the snow. No surprise there. That's one of the differences you pay for with the Desktop.

But I don't want audio channels... I just want the MIDI channels, which should not be an intense data stream requiring the amount of bandwidth that the TI itself does. But my understanding is general and maybe there are architecture reasons that present a huge problem to work around with the snow.

If it's not a technical limitation and simply a strategy on Access' part... I don't understand the logic behind that. Improving your most accessible range generally means that you get greater market penetration and that in turn, generates more revenue and mind share for the product manufacturer. It seems like a win-win feature to me.

Someone either has the money for a Ti or they don't... Improving how an artist interfaces with the snow may push some people to spend less money, but there will be plenty more buying a snow who wouldn't otherwise to offset the minority that can afford the Desktop.

When you said that you didn't have bandwidth, I assumed you meant USB bandwidth.

Did you mean internally in the snow?

Would an option of choosing which MIDI channel was assigned to each of the 4 parts in the snow be something Access would consider developing?

Would a solution where you have to disable them in groups be appealing?

Ie...

1 - 4 [Enable]
5 - 8 [Disabled]
9 - 12 [Disabled]
13 - 16 [Disabled]

So the audio stream available would only be in groups. Similar to having "pages" on the VST control.

I'm thinking that the snow would never be streaming more than it's current limits. That if you want to use a 5th MIDI channel, you have to disable one that you're currently using or if it's simpler to shut down the stream entirely, you shut down channels 1 - 4 and enable channels 5 - 8.

Sorry, I wish I understood your internal terminology better so I could communicate this more clearly.

Unfortunately, when I set automation it has to be on the master MIDI channel with the VST. The automation is also tied to the midi channel on the Snow, so this is where the root of the issue is happening.

I envision a process where when I run out of my 4 channels... I would record the individual parts as audio, switch to "Page 2" (Meanwhile channels 1 - 4 have been disabled by doing so) And I continue on, leaving all my automation and MIDI data intact on their respective MIDI channels 1 - 4.

This might be easier if I just drew up a diagram of what I'm talking about...

Agreed

I'm happy with the tech and the quality of the product, don't get me wrong on that.

It's this one interface issue that causes me a lot of trouble.

Do you have any suggestions for a workaround? I understand why you can't load multiple instances of the VST at the same time due to it being linked with hardware. But even being able to disable one of them and insert a new instance with 4 fresh channels would be a small improvement.

I want to make sure I'm not being misunderstood here either. I am only talking about MIDI access to the snow, not having more than 4 channels enabled on the snow itself. So the snow would still only be a 4 channel synth. I would just be changing which MIDI channel was controlling each of the 4 channels on the Snow.

I actually wouldn't mind if you were asking for continuity across the range. It's just good design. I think the VST control should be universal across the range because the fundamental capabilities are identical in oscillator choice, effects, arpeggiator, etc...

Personally, I don't care what upgrades a company might make after the fact, I have the hardware I do. I'm not going to get jealous that someone who has a different model than I got an improvement. That would instill more faith in the company and it's culture. I would be happy that I owned one of their products because it means that in the future... I will be treated with the same attitudes and desires for an improved product.

What I don't like is that it's an artificial limit being imposed on the hardware. Accessing 16 channels of MIDI is not exactly a modern feature... And I'm pretty confident that this is not how the Snow initially shipped when it was first made. My colleague swears that he was able to access 16 channels, but he did run out of voices VERY quickly.

What you paid for is the increased voice count and outputs and the additional hardware required to account for those things (which means you have less inconvenience of rendering to audio and maintaining greater flexibility). Because someone might have buyers remorse is never a good reason to weaken a product's design or not improve it.

Perhaps access believes it is making more money this way by forcing users who want the tool to be fully useful to dish out an extra $1000. But I know many people who are not buying the snow because of this workflow problem and the desktop unit prices itself out of their range.

But it appears that that is their strategy and making a simple improvement that already exists in other hardware of theirs runs counter to that. Personally, I think pushing more volume (by improving their most accessible model) is worth more in profit to them AND I get more usefulness out of the same tool.

That indicates to me where much of the company culture lies and there are alternatives to the Virus Ti Desktop at that price range that offer similar functionality and quality (And Keyboard Keys) so why make it more tempting for me to consider a competitor?

Sorry, but your analogy is flawed in this instance. Appreciable hardware differences, R&D and associated development costs are always valid reasons for charging more for different product versions.

I'm not asking a dealer to put the performance of a Ferrari in a Panda. I'm asking to add another door handle.

With a small change, that benefits your access' user group immensely, access will have made their hardware a better interface and more successful tool. At the fear that it will make the Desktop unit obsolete?

Access are the ones that developed a product range that uses the identical interface, yet "throttled" it's software functionality in the snow with a $1000 price difference between the next model. I don't see 12 channels of MIDI as a good value determination at $1000 for any consumer especially when the capabilities are identical (I use the desktop at work and I've had the keyboard as well).

Again, we're not talking about ANY performance upgrades in the Snow here. We're still talking about a synth that will run out of voices much sooner than your more powerful model options. There is still an inherent hardware limitation.

At this day and age, should you be surprised that users desire comparable software interfaces between models, especially when the software interface is identical in all other respects?

So is what your'e saying is that the lack of extra MIDI channels without any change in hardware is only so that you can upsell to the desktop unit?

Thank you for responding Marc

Well, this would have been one of the very earliest versions of the OS for Virus Ti 1. Around 2006.

I didn't have first hand experience with the snow then, but a colleague has told me numerous times that he had 16 channels available (but would of course run out of voices quickly).

So that might be incorrect.

The main workflow problem that I encounter is that when I run out of channels and would like to render a part to audio to free one up, there is no easy way to do so and retain or save the previous work for that MIDI channel.

I have to copy automation to a new placeholder track, move all the midi data over and then delete the old automation and begin trying to establish a new patch in it's place. It's time consuming and very inflexible and causes me a lot of production headaches. Especially if I need to go back to a patch and tweak it.

Had I access to more channels of MIDI (Even if only 4 were available to be active at any time), it would give me the ability to save those performances without having to do any track shuffling/juggling. I could just mute or deactivate that track and continue with the next patch. It would make the snow a much more powerful production tool.

Hope I'm explaining that well... I can be more thorough and supply screenshots if that is desired.

Updating first post since the thread has gotten so muddled...

If automation was able to be preserved and the snow could accept 16 channels of automation, it would allow a snow user to preserve these performances and re-adjust patches and parts after they have been recorded to audio without having to shuffle tracks and automation data in their DAW.

Mockup:

[Blockierte Grafik: http://www.straiusmusic.com/Access_Snow_MIDI_Input_Request.jpg]

Selectable inputs for the snow's 4 parts would make it easy to mute MIDI source tracks and continue assigning new automation parts as you move past 4 patches/layers in a project. Returning to a part that you recorded as audio would be as simple as loading your saved preset, re-assigning the part to your desired MIDI input and your existing automation assigned to that channel would continue to be valid.

This wouldn't increase the capability of the snow. It would still have all the same voice and part limitations, but would make it more flexible in rendering your MIDI source to audio and then returning to tweak if necessary.