Beiträge von js516k

The device manager does have a view that shows the devices by connection. You select it by going into the View menu and select "Devices by Connection". It looks like this:

[Blockierte Grafik: http://www.boomstickjoes.com/dev_mgr_sshot.png]

Zitat von mitchiemasha

I would of happily paid Access for the Distortion pack, when we got all those ice new pedal emulations. Especially, if it meant more for them to put into developing its OS. I'm sure many would agree and seen it as an investment into our product.

That is the model Line6 had taken starting with the PodXT and Roland with thier plug out system. Both are good models (no pun intended). Though I was speaking stricktly about the vsti and driver not the firmware, if an add-on/extension model was adopted to the firmware then it may pay for driver upkeep indirectly.

"Doesn't work" is not what I reported. I reported a reproducable crash during loading of projects that looks to be caused by memory corruption within the vsti. Quite a bit different. Most users just restart Sonar, I am required to report issues to Cakewalk.

Either way, my point was not to hijack this thread. It was to point out that software will eventually have issues that it didn't have before due to the changing nature of dev tools, os, and daw updates. My second point was that continued software updates from hardware manufacturers for older products is not a given and declines over time. I used my issue and experience as evidence for this.

I did contact Cakewalk and they analyzed the dumps and they found that the memory problem is within the vsti.

I also contacted support back in april. The information was forwarded to the Access developers and their response was that they are too busy.

Because there is not enough manpower to support everything on everything indefinitely and even limited support for older products is not cost effective. Access would need to buy all the software to test on and keep every version (not everyone updes\upgrades) with several pieces of hardware to host combination of patches or an it dept to manage virtual machines. Testing would be a continuous process. The price which folks would have to pay for the updates would be quite high to make this feasible. Even at my company we are forcing clients on an upgrade cycle because we are unable to support multiple versions of our product (note that it is singular) and its a software company. This is much worse in a company whose products are strictly hardware, which has a high startup cost. Most of Access' money goes to production and certification costs. A new product mean extensive prototype costs to he a piece of hardware the point where it can productionized.

Also, unless you are suggesting adobe style software licensing, there is no such thing as a steady stream of income for a company that makes money on sales.

Zitat von Marc

not here. but honestly Aj, i'm tired of repeating myself. do you really think we would ship a product which does not get something so fundament right?

Just wanted to chime in on this. Your product does not exist in a vacuum. What worked since the last release of the drivers and VSTi is not guaranteed to work today. This is the case with the current version of Sonar. Cakewalk updated to the newest VC and now the VSTi is throwing assertions and crashing because of memory issues which might be due to some compatibility change in newer MS' VC++ libraries.

You have a great product, but code rot can turn it into something unusable over time. It is inevitable. However, it is understandable that no hardware manufacturer will support the software side of a product forever as it is a never ending stream of unfunded work.

I understand it now. Thx for the recipe Oli but every hardware synth behaves this way when patches are loaded into the temp store( a.k.a. edit buffer). I can understand why a patch sent from the library instead of one on the device does not overwrite a rom/ram patch. It would be a nasty problem if it did.

The patch stored in the temporary store which is what you edit. Any time you select a patch, a copy gets stored in a temporary location in the ti's memory. The original copy is used for comparison and doesn't change until you store the patch.

When a patch is sent to a hardware synth into the temp store/edit buffer, there is nothing to compare against. I can repro this exact behavior on my jv2080. For example, if I send a patch into the edit buffer instead of a patch location, the "patch edited" graphic shows up on the screen and hitting patch compare brings back whatever patch was last selected on the synth. Hitting compare again brings up the sent-over patch.

This is worse on the TI because of the VST specifically designed to mimic a soft synth in behavior. Meaning, when using the VST, the hardware pretends to be a control surface and you are "suppose" to ignore the LED and display. Instead, you are "suppose" to watch the VST when editing, much like a soft-synth driven by a control surface. In this respect, the problem is that the hardware only does this half-way. The LCD and LED should be controlled by the VST instead of the local hardware, and should always reflect whats on the VST, not whats in the TI's memory. I.E. The vst should be telling the synth what the current value is, and the VST should turn on/off the led when the edited value matches/is-different-than the VST's original value.

Marc ia a forum admin who works for Access, not a user.

I don't have this issue with my Virus TI2 desktop which I bought from Sweetwater back in March/April of this year. I'm also in Windows 10.

The issue can be that the previous owner modified the patchs or loaded them from a modified set. I doubt if its any form of data corruption because the patches would be total gibarish including the patch name.

Maybe try loading it in a vsti hosting app to eliminate cubase? I use Sonar and although I can load it into a project, it will eventually crash Sonar but it doesn't BSOD. What is the error id on the BSOD screen?

I sent in a request in the middle of May about a VC stability issue in Sonar that was confirmed by Cakewalk. I made the needed files available to Access. The first level support folks got back to me in 24 hrs. I've emailed them a few times after this because although the 1st level support guys email back, I was supposed to have been contacted by a developer. Also I made the crash dump files available by uploading them to my webserver. They were never downloaded. When I asked about this in an email I sent in June, I was told that they are too busy to look at it. Unfortunately that means I can't use VC in Sonar reliably and it also sounds like the Virus is no longer a priority, so you have to wait longer for support issues that cant be resolved easily.

When you're selecting a patch, there is a segmented bar graph on the top right of the ti's display that shows the load/complexity of the patch you are using. The more complex the patch, the more load it puts on the dsp, the more dark squares are shown in the bar graph.

You mentioned that you are pushing about 8 tracks? It is very likely you are running out of dsp. You may want to try and simplify the patchs (like remove reverb, or reduce unison) and use the simplified version during the time that particular sound is not the main focus in the piece. That can help both gaining more dsp, and also have the sound sit better in the mix.

Makes sure the e-mr is delivering midi clock and not din sync. Sync24 (din sync) is not the same electrically and can damage the ti's midi port.

I don't think it is possible. However, why not run the backing tracks on output1, Virus on output 2, and have the virus generate a click to output 3? You would need to use multi mode and program a very simple single oscillator click sound.

Same here, but it occurs with Sonar Platinum (my system is all 64bit). I submitted a dump to Cakewalk which the developers determined to be caused by the Virus Vst3. I forwarded the dump files to Access Support early this month but have not heard from the Access Developers. I did get in touch with support again, but they had nothing on it yet as the developers are very busy.

I'm not sure on the Polar, but on the TI2 Desktop, if I hold down the audition button for more that a few seconds it will latch. You need to use the panic button combo to turn it off. It isn't a hold switch though.

Just wanted to mention that your website does not work on my android smartphones. All I see is the Duston logo for a few seconds before everything turns white. There is a two pixel sliver on the bottom of the browser which I can scroll.

You shouldn't see sparks flying out of usb connectors. If you do, there is a ground fault in either the mac or the virus.

Why not just use sequencer mode and set the bank and program number for a track as part of the track in the daw? The Ti's bank and program change is straight forward. I am even able to use my A70 controller to pull up scenes with layer/splits configured to use different patchs on my TI when its in sequencer mode. The configuration is stored in the scene on my A70. VERY convenient.

Manalyzer is not 100% accurate. Best bet is to use an accurate chromatic tuner which allows setting the reference pitch. Then plug your synth into that while tweeking the detuning. Remember to turn off all effects.

Most likely its a bad or dirty pot/encoder.