Blocks levels - please discuss!
Comments
-
I'm not advocating that every Block should aggressively clip the input for no good reason.
However, it would be nice if we could clip that input if needed, with the understanding that if it causes problems then we can blame someone else ;).
And yes I would be using an anti-aliased clipper... except in situations where it's purely for 'protection'.
an example with your -1..1 hard clip suggestion. mix 4 .25 amp signals together, then you are already at the max of -1..1. send it to a filter and you have zero headroom for the resonance.
I think a mixer is something of a special case - It's intuitive for the user that if they are mixing 4 signals together and the set them all to max, there will be some clipping. Also have to bear in mind that usually, signals will be uncorrelated, so mixing 4 magnitude 0.25 signals together will rarely get close to 1, so when it does, with some decent clipping, the results should be pretty musical (iirc, for N uncorrelated equally loud signals, the resulting level is something like sqrt(N)*level.. so those 4 magnitude 0.25 signals are likely to average a level around 0.5. There will likely be peaks due to beating and such if the sources are tonal oscillators, but soft clipping will sort that nicely... I suspect this is why NI went for 0.667.. mixing two uncorrelated signals at that level will give an output mostly just under 1.0... seems like a reasonable compromise...).
Mixing 4 magnitude 1 signals to a magnitude 1 output is also possible, but makes getting the UI tuned so it is intuitive to use more tricky, particularly if some blocks are outputting quite different levels... which is why being relaxed about levels is not good for Blocks. Its not so intuitive that mixing 4 signals would require all controls to be turned right down, particularly if they are connected directly to oscillators.
If some user has spent some time with the factory Blocks getting used to the 0.6 magnitude osc outputs, and has developed an understanding of where the good settings are on the mixer for nice subtle saturation, then they load up my amazing new world beating osc that outputs magnitude 1, it will sound ****** with the settings that to them should be 'about right'. Not a great thing. Once we get into more complicated patching, developing intuition regarding gain staging, mixer saturation, filter saturation, etc. etc. will be much more difficult if all builders use their own standards and approach regarding levels. The result of that is maybe Blocks don't seem as good as they could or should!
it's the big advantage of a pre wired synth. there you can make sure that levels match in a musical way. eg setting a good sensitivity of a nonlinear filter for the possible soundmix going into it etc.
This is a big part of the reason for this topic!
in a pre wired synth, it's easier to make things musical, for controls to make more sense with more usable ranges, more and larger sweet spots etc. It's not possible to achieve that to the same extent with Modular, but we can get close if we all use the same signal ranges. The more 'relaxed' we are about the specifications, the further away we get from that ideal.
I know these things are not deal breakers, and it might seem like making a big fuss about something relatively minor, but getting the details right does make a difference in how things are perceived quality wise.
0 -
I've never used blocks. Wait a minute, you mean to tell me they don't have basic input output gain controls. Stat's stupid is a stupid does. I'd just modify the blocks if you can with your own IO controls.
0 -
I've never used blocks
This thread is very much Blocks specific. Maybe you should have a go at using and building some Blocks?
1 -
Yeah, I agree, I do see the problem now, I had no idea they didn't have IO levels on the blocks. I was wondering why you brought this up. It guess they wanted to make it easy to interface any and all blocks with each other. I'll go and toy with it for a bit and find out.
Yeah, some blocks have no IO gains. Looks like they gave a levels block for that.
0 -
-1..1 would be nice and simple, and the louder things are the better they sound<<<<< This is simply not true. The preface for the discussion is false. I think you need to picture what actually happens to the perceived sound when it changes volume. I perceive less brightness in general, on the other hand turning up the bass compresses your ability to detect dynamic range of other sounds. I know it sounds weird, but I think it has something to do with excess pressure on the middle ear or something. Give it a try, take a base line and turn it up a tad and turn the other stuff down, don't exceed safe sound pressure levels for your ears. Check it out...
0 -
my amazing new world beating osc
yeah? way to bury the lede
first, for needing reduction in output gain with increasing number of signals , what about some kind of program dependency that scales the output depending oh now many signals it expects at its input? i did something like that but this was in a poly synth so the motivation was fundamentally misguided but seemed be sound in principle
personally if there's ever a way to use control systems or program dependency to respond to various use conditions in a way that is transparent the the end user control i go for it. often the result some new problem that;s just differently annoying but once in a while you can hit on something simple but feels like the kind of design secret that must have made some pieces of gear legendary
think with instruments tho being fundamentally something you want to control its better to optimize for that over "plug n play" (i strongly believe for instance that, say, a noise gate should not have a threshold control cause if basic functionality depends on tuning knobs esp more than one its asking people to crack your safe). but a musical instrument its hard to a way to do that in a way that doesn't hamper other ways one might want to use it
with my poly synth, even having set all volume controls to not follow snapshots,just browsing snapshots jumps wildly in output enough to cause heavy rage and bad sound. between just a filter, different envelope settings pulse width and the ability to selectively mute osc output that's plenty recipe for disaster. following the rough envelope of the output enough to apply AM level control was not a winning decision, obviously RMS characteristics of sounds different enough to cause problems will present different equally annoying problems to a system intended for automatic level control
for blocks oscillator levels, seems which level ultimately is chosen doesn't really matter as much as that everything is designed around one of them. which already is not the situation at hand, intractably. with that in mind:
it would presumably be trivial to detect which standard an oscillator was using directly from its output (at least assuming typical waveforms), given that, one thing i can think of some block if it had enough utility of its own, could get all oscillator into it first under the auspice of oscillator patchbay/parallel mixer/start your signal chain from a single point instead of hunting around the screen every time you want to start something new but who's primary purpose is more of a sleigh of hand to get em in one place and discretely in compliance with your preferred standard
admittadly this is as crazy as the problem itself. i was gonna say its more viable than finding a single level that isn't subject to problems when interfacing w/ different block standards, but only if through a design that defeats the point of blocks.. one principle that has not failed me is all information one could want about a signal is contained in the signal itself, but to be a magic bullet it needs some context for what you're looking for.
hmmmmm leaving sanity completely at the door i guess maybe its possible the inputs and outputs could be intercepted/buffered as needed with global event tables contraptions to send stuff wherever needed & keep track of what's what?
while i think advising users to be mindful of their levels, maybe mitigation strategies like signal level indicators on most inputs and outputs could make it manageable
0 -
yeah? way to bury the lede
That was hypothetical and also joking ;)
think with instruments tho being fundamentally something you want to control its better to optimize for that over "plug n play" (i strongly believe for instance that, say, a noise gate should not have a threshold control cause if basic functionality depends on tuning knobs esp more than one its asking people to crack your safe). but a musical instrument its hard to a way to do that in a way that doesn't hamper other ways one might want to use it
That's always a major design consideration. The compromise between ease of use and flexibility. It's something that's tricky to discuss here as well, because the 'right' compromise is often very different depending if the goal is a 'product' for other users, or some gadget for personal use. For the first, one would want an intuitive interface with simplicity consistency, while for the second, none of that really matters, because the user built it, so knows exactly how it works, and probably wants some detailed controls that tie directly to obscure internal parameters.
for blocks oscillator levels, seems which level ultimately is chosen doesn't really matter as much as that everything is designed around one of them. which already is not the situation at hand, intractably. with that in mind:
It does matter to the extend that different developers work to a different interpretation of the standard. To the extent that they are different, they are less compatible, and less intuitive to the end user (if that's themselves it doesn't matter, if its a 'market' then it matters a lot).
it would presumably be trivial to detect which standard an oscillator was using directly from its output (at least assuming typical waveforms), given that, one thing i can think of some block if it had enough utility of its own, could get all oscillator into it first under the auspice of oscillator patchbay/parallel mixer/start your signal chain from a single point instead of hunting around the screen every time you want to start something new but who's primary purpose is more of a sleigh of hand to get em in one place and discretely in compliance with your preferred standard
I'm struggling to follow what you mean, but I don't think it's practical, let alone trivial to 'detect' what interpretation of the standard some arbitrary third party Blocks might be using. The only way I can imagine that this would be possible would be some sort of envelope follower, but that is just not a practical solution. Having envelope followers or peak detectors at every input would just break so many use cases - remember that with Blocks we should be able to plug anything into anything else...
The only other option would be to expect that the user tunes their patch by ear to account for difference between Blocks from different vendors. That's the current 'system', and to me seems problematic. Is I've already explained...
one principle that has not failed me is all information one could want about a signal is contained in the signal itself, but to be a magic bullet it needs some context for what you're looking for.
Again, that doesn't really work in a context where we are developing modules so other folk can build instruments with them. We need to build modules that don't second guess the situation another person might try to apply them in, and yet still 'work'. It's really a huge deal in a modular context.
One of the major differences between digital and analogue, is that in analogue systems, stuff kinda just works like this, while with digital, it's much more difficult, and we have to jump through lots of hoops. The more flexible and transparent (from a usability POV) a DSP based module is, usually, the more fancy tricks have had to be employed by the developer.
That's getting away from the topic slightly, but it is somewhat related in that some of those tricks might depend somewhat on an assumption of the amplitude range of an incoming signal.
-----------------------------------------------------------------
There is a related issue, that in analogue modular, musicians/synthesists have to spend more time massaging signal levels for particular functionality... but it tends to be more intuitive. Precision requires more work. So in analogue, if you want to use the output of an oscillator as a source of sample and hold pitch values, you will likely need to put it through an offset/attenuator and tweak the settings a lot to get it within range. You might also need a buffered multiple and maybe other intermediate utilities... stuff that doesn't even make sense in the digital realm. In Eurorack, different oscillators from different vendors do put out signals in different ranges, however they are always well within the maximum possible range of the Eurorack format. It's then up to the user to boost them with amplifiers if they want saturation of clipping.
I understand that the clipping limit of hardware is an absolute practical reality, whereas from a general point of view, in software using floating point maths, it's not. The point of concern is that while the basic floating point signal chain doesn't have a hard and fast clipping limit, some dsp algorithms might have to define one, and it makes sense to consider that and stick to an agreed limit as part of the standard. But then that limit cannot also be used as the peak to peak output level for oscillators.
Blocks defines -1..1 as the range for signals. I guess my point is that if that's the clipping limit, then the 'target' amplitude for output level should be much lower, and that limit should be considered as a hard limit... while if the -1.0..1.0 is a target output level, then maybe we need to define a higher clipping limit... maybe something like -4.0..4.0. It's easy to say "no need, everyone can just make up their own...", but then we are back in a mire of non standardisation and minor incompatibilities driving more noticeable (to the user in terms of intuitive 'feel') compromises.
0 -
It does matter to the extend that different developers work to a different interpretation of the standard. To the extent that they are different, they are less compatible, and less intuitive to the end user (if that's themselves it doesn't matter, if its a 'market' then it matters a lot).
that's what i meant, as in if everybody had settled on one, any one of them could have been suitable. though i suppose keeping it under 1 could be a good idea even in the absence of a physical clipping limit as its conceptually useful. fwiw i'd probably pick .667, seems like a good compromise. i remember reading that FP resolution is slightly better between 1 ... -1 than between pi and -pi. wonder how much lower than .5 one could go before that started to become an issue again?
but short of a concerted lobbying effort seems the ship has unfortunately probably sailed (on everybody getting on a single standard). maybe the most rational way to go about it would be to gather data on what various developers ended up settling on and look for the closest thing to a schelling point?
I'm struggling to follow what you mean, but I don't think it's practical, let alone trivial to 'detect' what interpretation of the standard some arbitrary third party Blocks might be using. The only way I can imagine that this would be possible would be some sort of envelope follower, but that is just not a practical solution. Having envelope followers or peak detectors at every input would just break so many use cases - remember that with Blocks we should be able to plug anything into anything else...
yeah lol, it wasn't meant as a good or practical solution as much as a silly exercise in coming from the direction of what a technical solution would necessarily look like. its just interesting enough as a little logic puzzle that if what im thinking will work works perhaps i'll post a thread about it
0 -
Hi Andrew, just ******'n around a bit. These blocks should all have output levels to interface and need to be adjusted. Nothing magic needed, only what's missing. I was surprised to see that missing. This is what happens when skimping down on cpu usage by eliminating a crucial control such as an output level. At least the have a volume only block, it's a lot of space on your rack it you use a lot of em. So who knows why they did that. Nearly every block makes changes to the amplitude. So turn the feed into the block down so they don't clip. The first block in the rack can even overload, but not if you don't drive it so hard. I'd say one output level per block is fine for a straight serial chain. But if one block drives two or more blocks in parallel then a single input level would be better and no need for an output level except on the last block.
0 -
i remember reading that FP resolution is slightly better between 1 ... -1 than between pi and -pi. wonder how much lower than .5 one could go before that started to become an issue again?
It won't be noticeable in practical use. The issue is one of scale, if you perform arithmetic operations between values that have different exponents, you will lose information from the smaller number because the resolution changes as you change the exponent. Ideally you stay within the range of a single exponent, or at least close. Then everything will be just fine.
I really don't think it would be possible to notice any change in quality using -1..1 vs -3..3, as long as you don't take a signal in the range -1..1 then convert it internally to say -1000..1000, do some processing, then again to -0.01..0.01, more processing, then back to -1..1. You might start to notice then :)
Main thing to remember is that if you do have to change scale for whatever reason, you can process stuff using 64 bit doubles in core... That pretty much resolves the issue, unless you are intentionally creating a pathological case...
So if you are simulating something with a gain of 1000, then you might consider doing that in a 64bit macro...
but short of a concerted lobbying effort seems the ship has unfortunately probably sailed (on everybody getting on a single standard). maybe the most rational way to go about it would be to gather data on what various developers ended up settling on and look for the closest thing to a schelling point?
Absolutely, no point in trying to turn back the tide :). We are stuck with what we have, and have to make do with whatever compromise seems best. That's part of the reason for the discussion. What other folks do and why they chose to go that way.
I think in part it was down to me discovering that some of my Blocks that have been developed in sandbox situations are putting out quite low levels, while others are throwing out level often above the -1..1 range. I could spend many hours tuning and tweaking to get them all much closer to some accepted standard, or I could just leave them as is and let the (potential) user deal with it :)
e.g. I have a wavefolder that is modelled after a Buchla device. For most of the travel of the knob the level is pretty even, then at the last bit of the turn, it goes quite significantly louder. In a hardware modular context with generally more headroom than Blocks, this is just fine - the initial output is fairly standard, but if you push the dial, you get a hot signal - great for various reasons, potentially creative, characterful etc. But in Blocks, where many blocks are putting out -1..1, if I tune for that, and have the output across most of the range at -1..1, then when the dial gets pushed, it will be out of spec... maybe -1.4..1.4 But if I tame the overall output so that the hot end of the dial is close to -1..1, then the rest of the range will have a noticeable drop in output compared with the input waveform... not a good or intuitive situation!
So what I've done is change the folder so that it doesn't have that boost at the last bit of the dials Shame really!
0 -
Personally i like when the output level stays constant no matter what the treatment is.
I have always used amplitude curves on the output for filter res,drive input amount on filters and such so the output level is constant and i only hear the character changing,i find that most intuitive.
I want the signal to be constant from input to output of a block,module.
And if i want to change the output level i do this separately at the end of the chain.
1 -
Personally i like when the output level stays constant no matter what the treatment is.
Do you mean the peak level, rms level, perceptual level, or some other output level?
(I'm only half joking!)
0 -
I go by ear so i guess perceptual level? Hehe.
I usually use a few breakpoints for the curve and go by ear.
As mentioned here in certain situations it's not always perfect,for certain waves etc. but still steady most of the time i think,i adjust using a full sawtooth at the input.
1 -
Yeah, I feel the same way. Change the color but keep the volume the same. I think there is a "perception of volume" algorithm but I used straight RMS because is a general power sensor. I think the latter takes into account the frequency spectrum of the signal and how sensitive our ears are to volume changes in the different spectra. In reality though, I like the volume we perceive to be the same for any adjustment other than volume. It helps because volume changes attract attention. So it throws your concentration off, it's a distraction.
1
Categories
- All Categories
- 18 Welcome
- 949 Hangout
- 56 NI News
- 471 Tech Talks
- 2.5K Native Access
- 11.1K Komplete
- 1.3K Komplete General
- 3K Komplete Kontrol
- 3.9K Kontakt
- 843 Reaktor
- 299 Battery 4
- 612 Guitar Rig & FX
- 325 Massive X & Synths
- 762 Other Software & Hardware
- 4.1K Maschine
- 4.8K Traktor
- 4.8K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators