Beiträge von noct


    Indeed, and for that exact reason we need an updated manual instead of reading addendums. As you know, the manual for Virus C is way better compared with the manual for TI.


    I don't think addendums is the way to go. Otherwise, it's like saying its correct to have the manual for Virus A as a base, and keep releasing addendums for Virus B, then C, then TI, then each OS in TI... not correct :thumbdown:


    The addendum and errata have their place - if you're already familiar with the contents of the manual, you can just read the addendum to see how the new stuff works or what has changed.
    Personally, though, I would generally prefer to be able to refer to one source for all the information. I don't see that it would be that difficult for Access to add what they add to their addendum or errata to the manual as well. I'm sure they'll want an updated manual when they release their new hardware, so why not keep the manual up to date, then that's one less thing to worry about later?


    In a way, this is mirrored by Access' approach to software updates - many companies release a patches or updaters for their software, rather than requiring users to download and install the entire thing over again for each release. I mean this as an observation rather than as a criticism, but the processes Access follows for updating with regard to their manual and software suggest a more old school approach focused around major releases rather than constant updates. It may be that it is better for them to focus on getting everything right for a given release, yet there are always, and will always be, bugs in any software - which is why having a system where it is convenient for the developer to consistently release updates and the users to apply them has its advantages.

    It doesn't really surprise me if people are having more issues on the newer OSes, if the software was originally written for the older ones.
    I imagine that may be part of Access' motivation - it is more important for them to ensure their software works properly on the platforms people are migrating to than to maintain functionality on older systems. Ideally, they would be able to manage both, of course, but I have no idea what their code, requirements or the libraries they use look like.


    I will admit that I don't exactly produce much, I'm a hobbyist that always loved the Virus sound since I heard it in the 90s and bought one when I could afford to a few years ago (on that note, believe me when I say I can appreciate your feelings about the price of the Virus!).
    My reply was made more with my own perspective as a computer programmer as opposed to a synth programmer or musician (sometimes I get the impression people don't appreciate why a developer might make a decision like Access may end up doing, so I felt compelled to point out some of the probable reasons).


    That being the case, I'm sure I don't understand a lot of the issues you and others may have with migrating to a new system while in the middle of a project. From my point of view,
    it technically shouldn't be a major issue, so long as all your software works. I'm sure there's far more concerns than that though. So, I certainly don't mean to criticize anyone for lobbying for Access to not take a path that may cause them issues in their work.


    Regarding the Flash ROM, I seem to recall having asked about this some time ago, and that I was assured that there wasn't much reason to worry about it running out of "writes", so to speak.


    Regarding the polyphony, I'd expect the polyphony, if anything, would improve for patches not using OS5 features, but it's certainly possible that it would degrade; for instance, if a bug were introduced, or even if a bug were fixed, if the fix required changes that had a performance penalty. So without testing, I have no real answer for you on that.


    So far as installing multiple versions of the OS on one computer, which is what I assume you meant by VST2 and VST3, and whether that would allow you to select between them in your DAW, I'm not certain.
    It seems to me that the filename of the dll that is installed for the Virus VST does not seem to vary based on version, so you'd at least have to have to do something to keep them from overwriting one another on installation, either move them to different locations or try renaming them.


    I don't think there's likely to be a reason the path or name of the .dll should matter to your host, since I imagine your DAW doesn't assume a particular path/name, but rather just gets paths from you, and grabs .dlls from those locations. Therefore, it shouldn't care about names or any such thing. Assuming your DAW has you select VSTs via the .dll file names, you could then pick between them if they had different names. Just to be clear, I'm referring to the VST .dlls, e.g. Virus TI.dll or Virus TI Snow.dll, not the Virus Control.dll or Virus USB.dll. I suspect the VST .dlls probably use Virus Control .dll and would not work if that were moved.


    Note though, I highly suspect that even if you had all these .dlls installed on your computer, you'd only be able to *run* with whichever matched the OS the Virus itself was running; it just seems likely there would be some changes in the communications between the VST/dll and the Virus. Actually, the Virus Control.dll and Virus USB.dll could very well change as well, thus even if the OS on the Virus didn't matter, those files might have to have multiple versions and you'd possibly have to swap them back and forth depending which version you wanted to use.


    The above is all guesswork on my part though. It would be much better to get answers on these questions from Marc/Access. I'm actually curious about this myself, now that I've gotten thinking about it.

    To be fair to Access, there's a point where any software developer has to assess whether it's worthwhile to (officially) support a platform.
    They made this thread months ago to assess how many still use these platforms, and it doesn't seem like most do.
    Also, Microsoft itself must be near the point of discontinuing support for XP if they haven't already - it's very clear that Windows 8 is a major release for them, probably more important than any since XP.


    You suggest that since Access is a hardware company, they should be more receptive to supporting older platforms than if they were a software company. That actually seems backwards to me, since if their focus is on hardware, they probably have limited software development resources. Personally, I see them as a software company, for what it's worth; just their software happens to run on dedicated hardware. To that end, my view of the company actually makes me more receptive to your argument than if I saw them as a hardware company. Nonetheless, I highly suspect their resources are primarily geared towards programming embedded systems (dsp processors and hardware) rather than at an operating system or vst level.


    Also, I'm not trying to pick a fight and I'm not suggesting that Access should or should not give up support on these OSes - I honestly don't care either way - but isn't it a bit illogical to suggest that you need to keep using an old computer OS because that's what you've been doing your project(s) on for so long, but then complain that you can't use the new Virus OS; wouldn't continuing to use the old Virus OS that you've been using on your projects all along continue to work fine?


    One thing I do agree with though, if there reaches a point where the software will no longer work on e.g. XP, and they decide not to keep it compatible, they should branch it off and ensure the last working version remains available.

    I happen to be using OS 5, actually; probably should have mentioned it before, but I didn't think of it.
    I believe I followed your repro steps correctly, as I was able to notice this effect as well.
    I had:
    Osc 1 key follow at 0
    Slot 1 Dest. 1 -> Osc. 1 pitch, amount 0
    Slot 1 Dest 2 -> Slot 1 Dest 1, amount 0
    Slot 1 Dest 3 -> Slot 2 Dest 2, amount 32


    I kind of enjoy the effect, but I have the feeling most people would not.

    Thanks for the reply.
    Here is the patch setup:


    Osc 1 key follow: 0


    Slot 2 and 3 source are Key Follow.


    Slot 2 Destination 1: Osc 1 pitch, amount 0


    Slot 3 Destination 1: Slot 2 Destination 1, amount 0
    Slot 3 Destination 2: Slot 3 Destination 1, amount 32


    Regarding the saturation described, can you tell me if there is a usual result of this? For instance, if saturation were reached when attempting to control pitch, would I notice all note pitches being the same?
    Would they be at some extreme point (very high or very low pitches)? Just curious, as while I think I understand how this can be an issue, I'm not sure what troubles it causes or how one would recognize it occurring.

    Thanks for the answer and suggestions, flabberbob. I was actually hoping for an answer with such an explanation, so that is really appreciated.


    Extrapolating from your explanation, I tried a little test attempting "cubing" of key follow.
    My expectation was that middle C would remain middle C, the B below remain the B below, but the A# below would be equal to the E below, as (-2)^3 would be -8.
    I am comparing Osc 1 with modified key follow with Osc 2 with normal key follow; it could just be that my hearing is off, but it doesn't sound to me as if this is what happens, so I am again puzzled.
    It sounds more as if the pitch difference between notes is greatly lessened, many notes sounding almost the same pitch even.


    If you happen to understand what is going on in this situation, I would be happy to have an explanation for this. I don't quite understand what is going on with this, but I think if I did, I could probably make some use of this type of thing.

    Noticed something that (to me) seems odd, while trying to figure out a way to avoid FM in Wave mode from drastically changing the quality of the sound across note ranges (i.e. modulates at faster rate for higher notes).


    Set Osc Balance so only one Oscillator is audible (to make this more obvious). Then put that Oscillator's Key Follow to 0. Experimenting while holding a note when changing from 32 to 0 Key Follow, you will notice that lower notes increase in pitch and higher notes decrease - it seems some C in the middle is used a base pitch or something. I'm assuming this is what leads to the odd behavior that follows.


    With Key Follow set to 0, go to the Mod Matrix and set Slot 1's source to Key Follow, and its Destination to the Oscillator's pitch. Set amount to 32, notice that the Oscillator's pitch matches what it normally does with its own Key Follow at 32.
    Set Slot 1's amount to 0, and set Slot 2's Destination to Slot 1 amount. Set Slot 2's amount to 32. Notice that low notes now effectively play backwards (edit: while high notes continue to ascend almost normally, though they cap out early).


    Not entirely certain why this happens. I don't suppose anybody has any thoughts on making use of this behavior?

    If I recall correctly, they can be used with the Virus B, but probably not all will sound the same due to some patches using TI features unavailable to the Virus B.

    Not very important, and I'm not sure this is the place to report it, but there's a typo in the subtext for the Feature Requests section.


    Where it says: The Virus is know for frequent feature upgrades. Let us know what you would like to see in the next version.
    It should be: The Virus is known for frequent feature upgrades. Let us know what you would like to see in the next version.

    When editing the Mod Matrix using the Parameter buttons to move between Destinations, if you go back from Slot 1 Destination 1, you end up at Slot 6 Destination 3.
    Likewise, going forward from Slot 6 Destination 3, you end up at Slot 1 Destination 1.
    So the menu wraps around in this situation.


    However, this behavior does not occur when using the actual Mod Matrix Destination buttons in the same manner. Attempting to go up from Slot 1 Destination 1 goes nowhere.
    Likewise, attempting to go down from Slot 6 Destination 3 goes nowhere.


    Would it be possible to make the Mod Matrix Destination buttons function in the same manner as the Parameter buttons so far as this behavior is concerned?

    It's a minor quibble, and maybe I'm just missing something, but my issue is this:


    Select, for example, Oscillator 2 and edit, and move to edit page 2.
    Now edit anything else, then hit the Oscilliator edit again. Notice you're brought back to page 2, the edit page you had been at last.


    Now try the same thing with the Mod Matrix:
    Select the Mod Matrix, move down to Slot 2.
    Edit anything else, then hit Mod Matrix again. Notice you're brought back to Slot 1, rather than the page you had been at last.


    As said, this is a minor complaint, but it'd be nice not to have to hit the Mod Matrix button six times every time you want to return to editing Slot 6,
    and to not have to remember which slot you were just editing every time you leave the menu.

    Zitat von janchlupacek


    When Virus exports the MID file, what is actually inside of that file?


    The .MID files contain patch information for the exported bank. Potentially there is other information there, I'd have to look into it to determine what else might be there.


    Zitat von janchlupacek


    Second question is related to this...is it possible to somehow see those settings?


    Sure it is, after all, it contains all the information the Virus needs to load a patch.
    However, Access knows how they store the data in the .MID files, what each part of the file means to the Virus, and we do not.
    At some point, I may return to a project of mine, where I was attempting to reverse engineer this very information. However, unless somebody suggests a better method to do so, it's a very tedious task.
    My methodology was to make a patch, change one parameter on the Virus, and compare the old .MID file with the modified one. Well, there are a lot of parameters in a Virus patch!

    "With all the hype about the release of os5 and some serious issues already have surfaced."
    I feel I should point out that OS5 has not been released. The OS5 beta has been released. Issues are to be expected.
    The primary reasons for releasing a beta to the public are to find issues that a small QA team testing on a limited number of system configurations may not encounter, and to get feedback from users regarding any new features added in the new OS.


    Having said that, I would be interested to hear answers to your questions as well, out of curiousity.


    My own thoughts on those questions:
    1/ There are only two main platforms to develop for Win and OSX, so once developed should, everyone discover the same problems?
    There are multiple supported versions of Windows; I believe OSX is in the same position, though I am not an Apple user, so don't quote me on that.
    Bear in mind though, even if they were all the same operating system, there can be many different hardware differences, and for that hardware, different driver software.
    Also, an operating system is a complex piece of software in and of itself, which many different ways to configure it, and that's before considering that not everyone is running a fully updated, identical operating system install.
    On top of all that, there are the different supported DAWs to interface with as well.
    In other words, there are a lot of variables.


    2/ How many chipsets does the Virus have over the whole range and how does an update affect the interfacing between hardware and software?
    I would be interested in an answer to this.


    3/ With the previous updates, should the previous stated bugs be ironed out easily?
    There are bugs, and then there are bugs. Some are more difficult to fix than others. Some are more difficult to reproduce in a reliable manner. A thought to ponder: if one can't reproduce a bug, how do they test that it has been fixed?
    So in the end, it depends on the bug.

    Is there a complete list of changes/fixes somewhere? I can't really find anything other about smaller fixes, just the mention of new Env's, effects etc.


    There should be a link to download the change log beneath the button to download the 5.0 Virus Control/OS for your computer's operating system (under the date/filesize).

    I can see these new envelopes and filters are going to be a lot of fun, thank you Access. I do have one question - is it possible to control Envelope 3/4 without using Virus Control? Whether directly with the Virus, or via MIDI?

    Due to the number of routes one might take in designing a sound with the Virus, I don't think there's one particular setting that can be adjusted to make all Virus patches sound sizzling/warm.
    I do find it a bit surprising to hear it said that the Virus (and for that matter, Sylenth and z3ta) sound mediocre; they all sound fine to me.


    Edit: note that the Nexus I'm referring to is the reFX Nexus 2... if you were talking about the Tyrell Nexus 6 or some other synth, just ignore everything I said, though please elaborate on what Nexus you were referring to and provide a link to some demos or something in that case.


    So far as the Nexus sound is concerned, I listened to their demo video and can't say I heard anything I thought was new or original. I'm sure the presets are useful if you're looking to imitate the current popular sound though, as it does have a very polished sound to it, no rough edges. Keep in mind that the Nexus seems to layer up to four sounds per patch, so it may be a bit unfair to compare a single Virus patch with a Nexus patch.


    I didn't look much into how programmable the Nexus is, but considering that the video didn't focus much on that, and given it is a ROM based synth, I would not expect much on that end. I would be surprised if it had anywhere near the capabilities as the Virus has in that regard, but given you seem to be concerned with presets, I doubt that's a concern for you.


    In the end, it all comes down to what you are looking for. The Nexus is probably good if you're looking to throw a song together in a hurry, while the Virus would probably make the Nexus look very bad if you decided to create some new sounds (based my my own experience with ROM-based synths, though I admit I have not used the Nexus, and for all I know it is incredible to program). Also, in my opinion, at least, there are plenty of good sounding presets on the Virus, too. The Nexus definitely wins on price though, gotta give it that.


    Sorry I couldn't help you make your Virus sound how you like; maybe somebody else will be more helpful in that regard. Probably flabberbob, that guy is like a sound design god or something, judging by how he answers seemingly every question about sound design on these boards.

    "But i found out something strange; when i trigger a note with my midi-keyboard i hear that lfo effect, but when i trigger a note using the piano roll of my daw the lfo effect is gone!"
    "I also found out that when i trigger a note using my keyboard and i put the phase init of my Virus to 127 the lfo effect is gone aswell"


    That would imply, to me, a control related issue. Perhaps your MIDI is setup in such a way that you're triggering the same note twice when you play one on the keyboard, and they end up slightly out of phase or something (not sure that would cause this).
    I'd look into that; perhaps you have a MIDI connection between the keyboard and Virus, and another from the Keyboard to the computer to the Virus? Or some other such thing, there's probably lots of possible configurations, but this seems a likely enough cause to me.