Beiträge von neuromodulator

  • MWQuant BC showing matrix destinations "-reserved(73)-"?

    I think there's an OS glitch with patch ROMB-67 (MWQuant BC) where the mod wheel destinations read "-reserved(73)-" and "reserved(74)-" from the front panel, and show as blank destinations when viewed from the plug-in - but they still work. Does anyone (Ben?) know what they're controlling? I'm going to try and figure it out, but thought I would ask/report the bug in the meantime. I'm on 5.something, can be more precise if required.


    Cheers.

  • Feature Requests and Design Philosophy

    So I wish people would think about their suggestions in light of these kinds of ideas. The first step is thinking, “Would this actually sound interesting or am I just really stoned?” (we’ve all been there). But if the answer is that it would sound interesting, that’s not the last step. There’s a bunch more.


    How would this be implemented on the hardware? Realize that menu-diving and shift functions are always less than ideal. Those are downsides. They’re immediately piled on the opposite side of the scale to the benefits from your proposed function. Software-only control is an order of magnitude worse than this. That’s a serious, last resort type thing.


    Does this suggested change fit what I believe the Virus to be, or is this more of an “everything and the kitchen sink” type suggestion?


    Does this suggested change have broader implications than I have imagined? Does this mean that the Virus now is competing with capable products that it now needs a host of other changes to compare to? (For instance, sampling isn’t just sampling. Can it sample from the audio inputs? Loop? Normalize? Detect tempo? Slice? If it can’t, is it worth implementing a half-assed sample function? It may be, I’m not answering that, but trying to make clear that suggestions have implications).


    I don’t mean to be super critical of anyone here, or single anyone out. And I enjoy your enthusiasm. I just feel like this needs to be pointed out, and discussed, and also considered when Access doesn’t implement your particular suggestion – they have reasons beyond “it would cost too much financially”, and they are good reasons.


    Cheers.

  • Feature Requests and Design Philosophy

    I feel like I might get flamed a bit for this, because I’m going to be presenting a case for why I think the things some people ask for are wrong. I do recognize that this is just my opinion and don’t mean to be come across as super arrogant, but at the same time I do believe my opinion is right ☺.


    (Also, I posted a snarky reply in the thread of the person who wanted to be able to draw his own waves – this post is me trying to explain that snark, post something productive instead, and also apologize. Wasn’t very cool of me.)


    So as the thread title says, this is about feature requests. Now, I spend a lot of time on the forums of various software and hardware manufacturers – all the gear I own and a few that I don’t. And on all of them (except maybe the Moog forums), the site is full of feature requests where people seem to be posting things along the lines of “wouldn’t it be cool if this could do X” where X stands for EVERYTHING I CAN THINK OF. There seems to be a push for each piece of software and hardware to be able to do everything that every other piece of software and hardware can do. They want to mutate everything into uber-gear, and I guess then only need one piece of software/hardware.


    And I get that from a theoretical perspective: it would be cool to have one synth that can do everything that any synth can do and thus never need another instrument.


    But there are a bunch of real-world considerations that make that idea wrong, when you think about it in more detail.


    (As a special aside here, I think we need to address the “I’ve got this idea that sounds cool in my head but doesn’t actually have interesting real world applications” type of idea separately. This is super common, actually. An example from these forums that springs to mind is when someone was asking for fractal LFOs. I’m not talking about the recent post with the diagrams of new waveshapes with one described as “fractal”, but rather an older thread where it sounded like someone put together the idea that “fractals look cool” with “I wonder what that would sound like”. The answer is: not very interesting in any way. The interesting thing about fractals, visually, is how the detail on smaller scales mirrors the detail on larger scales. That doesn’t translate to anything interesting in the audio realm because the nature of our modulation targets means that we would only maybe hear two or three orders of magnitude, tops, of similar structure – and the higher, smaller ones, would be producing tiny tiny modulation effects. It doesn’t really make sense as an idea. These kinds of ideas are all over every forum, and since they’re not even practically applicable, I feel that what I’m writing below doesn’t even apply. It’s even possible that I’m wrong on this particular example, that there’s some synth that uses fractal LFOs and they sound amazing, etc. but even if I’m wrong on criticizing that specific example, my general point still stands. I’m not an audio engineer or a mathematician, so I recognize that I don’t really know what I'm talking about.)


    The problem is this: every object I have which I have any real fondness for is the product of a fairly strict design philosophy. This is a set of ideas about what that device’s purpose is, and how it’s used.


    I really love my Virus. I mean I seriously, deeply adore it. I think it would actually be my last possession I would give up. And I think that part of the reason that it is, to me, a profoundly beautiful object, is because Access has a very well-designed and implemented design philosophy. It’s a tightly focused thing.


    The issue with a lot of these suggestions can be understood with that in mind: are they in accordance with the design philosophy? Do they fit the sonic goals of the Virus, or would they be a broadening of those goals, and if so, would that be a loss of focus? Do they fit the flow of the hardware controller, or would shoehorning such-and-such a feature in be a really awkward fit?


    Let me talk about a really simple example of a possible design philosophy issue: loopable envelopes. It would be really simple to implement loopable envelopes, on a software level, and I do hear it requested. There are serious issues to implementing it on the hardware side: there is no dedicated switch for it and no indicator available to show whether looping is turned on. No dedicated switch necessitates menu diving – and that’s a design philosophy issue for the Virus, right there. Here’s a piece of the Virus philosophy: menu diving should be kept to an absolute minimum. I think the indicator is probably also a top-level philosophy issue: first order sound design features (which is a term I just made up to apply to “key” traits of a sound, as opposed to “subtle” traits of a sound) should have an indicator on the controller that doesn’t necessitate peering at the LCD screen. I think there are issues with the idea that are opposed to the philosophy of the Virus, and that implementing those ideas would move the Virus away from being the tightly-focused thing that I love.


    Now I’m going to posit something further about the Virus design philosophy. This is more of a guess whereas I’m more confident in my affirmations in the previous paragraph, and it’s a bit more subtle. I’m going to guess that part of the design philosophy says: “LFOs take care of repeating modulations, and envelopes are for non-repeating modulations”. So loopable envelopes directly contradicts this axiom. Why would we have such an axiom? Because it keeps the Virus clean, conceptually. It lets a user make assumptions about a sound – when we hear something, it lets us guess that the LFOs are the source of a certain type of modulations. (Yes, LFOs in envelope mode add a bit of complexity to this idea. Wouldn’t it be cleaner, conceptually, to say also “one shot modulations will be the envelopes only?” Well, yes, but two things: one shot LFOs are part of the tradition of the analog synths that inspired the Virus, and there’s always a trade-off. The gain of having envelope mode for LFOs is substantial, whereas I don’t see a similar gain for loopable envelopes.)


    So that’s a dead simple example. The cost to design philosophy increases exponentially with some of the examples people suggest. A third envelope is super popular, and does have obvious practical applications. But how do you deal with it on the hardware side? Right now the envelopes have a top level control priority. Implementing a third one would hurt that. (I personally find having slope relegated to a shift function bad enough). They also hurt the intuitive aspect in that now you’ve got to do more wondering about what control source is producing which modulation you hear. Right now, we have a knob for each of the eight main envelope functions, and an LED for each LFO level, so we have a top-level “at a glance” view of potential modulation sources. A third envelope, while useful, mars that “at a glance” concept – it contradicts that aspect of design philosophy.


    These are basic, basic ideas – loopable envelopes or third envelopes – that don’t even touch on introducing new sonic concepts. Design philosophy issues become much more threatened by things like user-drawn waves. (I personally object to user drawn waves because I feel like they’re something that sounds much more exciting on paper than the practical uses of it, but I recognize that’s a bit different than design issues). Right now, the only thing you can’t do on the hardware is design user arpeggiator patterns. I think Access should be (and I think Access is) very cautious about expanding that list. That’s another top-level design philosophy issue (and I bet there are engineers at Access who are bothered by the fact that they couldn’t figure out a practical way to do it on the hardware).


    But more than control issues: that’s a serious broadening of what the Virus is. That’s a bigger change, I think, than sample playback would be, to give some reference of scope. And it throws the Virus hat into the ring with products that are really good at user-drawn waves, like Absynth and Zebra. I feel like the idea has implications, such as “if you allow user drawn waves I think that design philosophy suggests that you also need Absynth-style complex envelopes”. And that blows the concept of the Virus wide open, and it becomes something unfocused. It is no longer a tightly designed object.


    None of this even touches on another really Big and Important concept: the Virus is an instrument. Instruments need to have character. I don’t want an instrument that does everything I can think of. A beautiful, well-made tool is for a precise purpose, not a broad purpose. A computer is a broad-purpose device, and that’s why they’re not satisfying as instruments (I think this can be accommodated for with careful consideration and intelligent design of controllers but I’m trying to illustrate a point, if you see what I mean).


    (Another aside: this is why the “new LFO shapes” post is actually a good suggestion. Do those shapes have practical applications? Yes – I can look at the pictures and hear the effects. Does it have a design cost? Not that I can see, in that it would simply add a layer to the “waves” section of the LFO menu which already exists. “Not that I can see” of course doesn’t mean that I’m not overlooking something.)

  • Unipolar vs Bipolar

    Ummm, Merlin, that is incorrect. Unipolar does not have an inverted half-cycle, it's applied as an offset.


    mclifton, imagine it like this: let's say you want to use a square LFO to modify pitch. With bipolar, you'd be setting the pitch of your oscillators, and then applying the modulation, which would result in your patch having two pitches: one below the pitch you initially set (for the lower part of the LFO cycle), and one above it (for the upper part).


    With unipolar, you're only pushing the pitch in the direction of your modulation amount. You still get two pitches, but if you're using positive modulation, you're getting the original pitch you set, and a higher pitch - never a lower one.


    This makes it a bit easier to control some modulations - like in the above example, you might want one of the pitches to always be the actual note you're playing on the keyboard. With bipolar modulation that's much trickier to do.


    This might make it easier than the wordy method above:


    If you set LFO 1 Bipolar to modulate Oscillator 1's pitch with a modulation amount of 12, and hold down C3, the notes you hear are C2 and C4 (again, with a square wave because it's easier to hear).


    If you do the same thing Unipolar, you get C3 and C5. So you see it's still jumping two octaves, but the lower note is the key you're holding, and the entire offset is upwards, instead of the first case where the offset is above and below the note on the keyboard you're holding. I hope that's clear?

  • weak oscillators

    I did some A/Bing of raw oscillators of my Moog Voyager vs. the Virus and was forced to admit that you guys have a point.


    I do want every instrument I own to have its own character, so I'm not entirely on board with the "it needs to be able to do X because other synths do X". But the raw waveforms do sound muddy compared to the Moog's, which sound very "crisp".

  • virus tutorial book outdated ?

    bagpula, I understand that you're frustrated, but I think you would find more people inclined to help you if you stopped framing everything as an attack. Everything is a flaw in the gear or a flaw in Access' support, when, honestly, it's clear that you just don't really understand what you're dealing with.


    The reason there doesn't need to be a ton of detail in the mod matrix section of the manual is because it's not really introducing new concepts. It's about modulating existing parameters which are all pretty clear to someone with an understanding of the fundamentals of synthesis. If you're modulating a filter parameter, an explanation of that parameter is in the filter section. If you're modulating an oscillator value, an explanation is in the oscillator section. It doesn't warrant some type of super complex explanation in and of itself because it's all about routing one thing to another thing.


    You've made it clear in some other thread that you want to present yourself as some degree of expert, but you've also made it clear with the things you're asking that you're not actually super familiar with synths. That's okay, that's %100 cool. There are times when we all weren't. But it would be cool if you dropped the "I'm an expert and this is a piece of junk" routine, and then we could start addressing what you don't actually understand and why that's confusing you.


    Howard Scarr wrote the tutorial guide on his own free time, I believe, and kindly allowed Access to continue to publish it on their website. He doesn't work with Access any more. The principles he describes in the guide still apply to the latest OS, and the inclusion of all the new features and whatever wouldn't really change the things he's saying, believe it or not. He's doesn't need to talk about formant oscillator modes because it's not super relevant to the basic principle type stuff that he's writing about. The guide is still an excellent place to familiarize yourself with the basics.


    The complex oscillator types do take a bit of work to wrap your head around, but they're covered really well in the tutorial videos - they're explained at length in the manual (or the addendum) too, but the complexity of them makes the language a little hard to parse. Access has one of the most clearly written manuals I've ever seen, but I'm getting that I have a head for reading technical descriptions when you prefer to learn in other ways.


    If you can try to articulate what's confusing you without arguing or ranting, I'll be back to help, but if you just keep on with the same attitude I'm done reading your threads. Your choice.


    I know this sounds a bit harsh, but it's well meant. I'm really hoping we can move forward in a pleasant way, because I enjoy helping people.

  • new setting for modulation pedal?

    Yeah, that would work. It might be a bit confusing to have, say, an LFO flying around and affecting whatever parameter you adjust, but I think it would be easy to avoid that confusion for people who are uninterested, and would make some weird dynamic patches.


    Your idea would address my pedal issue, but if for some reason yours is unworkable, I'd still appreciate it if access would consider my simplified pedal-only version.

  • new setting for modulation pedal?

    I had an idea tonight that I would absolutely love to see in a future Virus OS.


    What I was thinking would be to have an option in the modulation pedal assignment for dynamic reassignment. What I mean is that if you dial up the "dynamic assignment" mode, what happens is the pedal then controls whatever parameter is currently selected for editing. That is, when you're looking at a parameter on the Virus' LCD display, the pedal modifies whatever has the little triangle over it. Let me give an example.


    So let's say I've got "distortion" selected and I go into edit mode. On the first page, you see "type", "mix", and "intensity". If I stay on that edit page, whichever parameter I adjust gets a little floating triangle over it, and what I'm proposing is that whatever has the little triangle over it becomes the controller pedal destination. This would give me the ability to very quickly do some pedal reassignments.


    If no parameter is selected for editing, I would suggest either the pedal setting is "sticky" (i.e. it remembers the last parameter assigned) or it reverts to CC#1/mod wheel.