Why is there no frequency dial?

#1

title says it all... why oh why is there no frequency dial available? one where i can input 500 hz with my keyboard and hit enter and it will translate that (or the nearest possible frequency) to the range of -64 to 64. this would be so much easier to dial in. in the meantime i made a puredata patch that does the math for me.

here is the puredata patch:

#N canvas 632 169 450 300 10;
#X obj 152 86 ftom;
#X floatatom 152 62 8 0 0 0 - - -, f 8;
#X obj 152 117 - 64;
#X floatatom 152 149 10 0 0 0 - - -, f 10;
#X connect 0 0 2 0;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#2

why is there not X?

because its not been implemented yet, and there is a limited amount of time in a day :wink:

if you want to enter frequencies, you could use an integer box, and then use a simple script to convert from HZ to frequency. (you could do with a subpatch too, but you are already working with custom objects, so probably easier to do that!)

#3

i understand. it's just that axoloti is a tool to make music (among other things of course) and as a musician i think in frequencies, i can hear a tone and name that frequency. having to translate this all the time to the -64 to 64 range is just a waste of time :slight_smile: but i totally get that this is not the only way to look at this. i was just truly surprised it did not exist, as i also have seen so many requests for this on the forum. (along with bpm input)

so, i will attempt to do this, my first try already failed :wink: will maybe post back with some questions if that is ok.

thanks for all the help so far, really getting great stuff out of the axoloti.

#4

ok, so i basically don't get it. i found this post by johannes: https://sebiik.github.io/community.axoloti.com.backup/t/hz-to-phase-increment-value-formula/2046/2?u=lokki

which seems to say, that there is a simple hz/phase increment mapping. but i think johannes misunderstood the question, right? or i misunderstood the question andor answer :slight_smile:

i thought the -64.0 to 64.0 range is basically midi notes, but with fractional "notes" in between and the 64 offset. so i think the following should get me there, right?

outlet_out is frac32.bipolar
param_hertz is int32

outlet_out = 69 + 12x(log(param_hertz/440)*3.321928095 - 64

3.321.... is 1/log(2)
i understand i need to bitshift here and there and probably have to replace the 3.321 float with a bitshifted fixed point value. and that is where i'm lost. do i also have to bitshift all other values to get them" in range"? i think i need to bitshift the final result by 21 , but that does not work because of double and int mixing. can anybody shed some light on this? sorry for so many questions.

#5

I'm not quite following what your trying to do here...
( could be its late, and tired though :))

Axoloti has frequency and pitch inlets - The former is a unipolar float, later a bipolar float.
You can of course convert between them, but they are used in different places.
( phase increment is something different again, not usually seen by uses, as its used internally when creating oscillators etc)

Soooo , you could create a frequency control, but you would only use it with frequency inputs, similar you could create a pitch control for pitch inputs.

... But connect a frequency control to a pitch inlet and your would need to convert or you would not get what you expect.

.... And this is partly why there is no frequency dial, Johaness wanted ( at some point) for dials to know what they were connected to and then automatically show the appropriate units - but that use case has quite a few edge cases, and is more complex to implement that just a new dial.
( this is from memory, so is subject to confirmation :))

#6

what i want would be a way to enter 2000hz or whatever hz in any oscillator/filter dial. (and then internally convert it to -64 64) but since that is not what is going to happen i think i need to convert from frequency in hertz to pitch input. hence my frequency to midi formula. most of the oscillators and filters i use from the library do not have a freq input...

but maybe i just have to adjust all of the objects i need and add a freq inlet.

sorry i am so stubborn about this, i just think it is a VERY important feature to have. to think of music only in pitch terms (be it semitones, or any subdivision) is just very clumsy (for me anyways)

#7

yeah, sorry, I didn't meant to suggest this was not necessary, or that axoloti was 'correct as is'

perhaps sometimes my posts come across as defensive, which is not the intention.
(Ive no need to defend, its not usually my design/implementation)
my posts are more, about 'this is whats currently available', or to provide an insight into why things might be as they currently are... none of this is to say it cant/wont change...

this is probably my mistake, as frankly, I love to know how stuff works, and why its been done the way it has... and often forget, that many are not interested in this... they just want it to do what they need it to do :slight_smile: (which is understandable)
... and of course, being an (amateur) musician myself , I also know, when making music, i want to deal in musical terms , and the technicalities can get distracting!

anyway with that all said, let me give you a couple of other 'tidbits'

frequency dial
... as you can perhaps see from the discussion, the dial is not the issue at all... what your real request is, is for a frequency input on objects (as well as pitch)

you can actually make your own freq/pitch dial very easily
grab a dial/p , embed object, then go to the parameter page, and change the type to frac32.s.map.pitch (or similar)
... but as i said, that doesn't solve your problem :wink:

let me also answer your first question...

this could be rephrases as why do we have -64 to 64...
well this comes from real modulars, and CV, which use -5v to 5v...
imagine this as -64 to 64v and then axoloti basically works the same... where the voltage translation on an input, is done by the receiving module.
i.e. in a real modular 0v only means C3 when applied to a 1v/oct input, when its applied to a decay modulation input, it might mean 3 seconds...

why do we use -64 to 64/0 to 64... well this comes from the Nord G2, its done like this, so that it maps 'easily' and visibly to midi (0..127) , its not limited by midi, but makes 'detents' obvious.

sure not great for user input, but its amazingly flexible.
(and of course in a virtual world, we have the option to try to be a bit better than a real modular)

also one thing to take care on...
when you do these translations of 'voltage' to 'user value' in axoloti we usually do this in the UI layer, i.e. the java code, so that it doesn't take precious resources away from the limited processing power on the STM chip on the axoloti...
the DSP processing power you want to be used for audio processing, not translating values for the user, which the axoloti board does not need to use.... this is just a waste of resources, where resources are at a premium. (your desktop has plenty of power to spare)

what does this mean? well really if the user wants to see frequencies instead of notes then ideally this is done in the java/UI code.
BUT this is not that 'straightforward', since one is a linear scale, and the other is exponential , so might feel a bit 'odd'

anyway, as I say, not meant as an 'excuse' or defence, or to say things are subject to change...
axoloti is actively being developed, so is always in a state of flux...

but hopefully this gives an insight into where its at, why its like it is for now.

but your points are clear for future developments.

#8

cool, and the point about linear vs exponential is why i tried to do that stuff with the freq to midi formula. i think i understood the basic concept (midi offset by 64 with fractional) before, but i have not the "technical language" to explain myself correctly in english sometimes :slight_smile:

anyway thanks for all the insight, you or your posts did not come across defensive, no worries.

i also thought about it some more and have found that it would already be very nice to get a little helper app (or object) that does the numerical translation, so that one could then input the pitch value (derived from frequency input) into a pitch dial of any filter/osc...i will try to do this.

#9

i understand how modulars work, and got the similarity of the concept, i think it is great and very flexible as you say. but, even on a modular the ui (i.e. knobs, sliders, a keyboard) usually have no -5v to 5v writing as labels but things like frequency in hertz or bpm :slight_smile:

i think my brain may also be so used to puredata, where you add a mtof before the oscillator if you want axolotl behaviour, that i just don't "understand" why there is no ftom module in axolotl that does at least the inverse. :wink: here to learn!!

i think we are not so different in this matter, just that i know more about music and less about math/programming. for you it is the other way around i suppose. my experience so far has been, that i can get pretty far with programming what i need, but in every new "framework" i need quite some material (source code) to study. on the axolotl the barrier to enter is very low from the ui (with the object editor) but a bit higher programming wise because there is so little documentation. i will get there though, it will just take time. did it with arduino, puredata, preenfm firmware etc. will get my head around axolotl as well :wink:

cheers

#10

Pitch and frequency parameters are already labeled with associated unit conversions: ((k)Hz, note name, transpose factor) (click on the frequency label to cycle through other units), and indeed frequency, note name or transpose factor can not be entered via the keyboard.
The way I envision handling this (to be developed in the software, not in objects), is extending the value input parsing (when a parameter is focused, you can type a new value, press enter to accept, esc to cancel) with associated units converters. That requires detection of the relevant unit from the input. So to enter the frequency you'd need to enter "440hz" or "1.76khz". To enter a note name you 'd enter "c4", "B5#+22" or "B2b-10".
"ftom" is a bit weird, computationally more expensive than "mtof", I see little use for "ftom" in usual patches. It can be approximated with math/log, math/-c (14.5), math/*c (48), math/muls 2 in a chain, when the input maps 0-64 to 0-nyquist.
BPM still poses a different issue: people most often use whole numbers for bpm. Mapping bpm on a logarithmic/chromatic scaling does not result in round bpm numbers. Mapping a 0-64 parameter range to its double value in bpm stops at 128bpm, too slow for some genres while a parameter unit tick would already correspond to 2bpm difference in speed. Offsetting that range by 64 bpm would limit the range to 64-192 bpm, still no good fit for all genres. The Nord Modular uses an odd scaling where a unit tick corresponds to a 1bpm difference between 88 and 152bpm, and 2 bpm/tick below and above that range, resulting in a total range of 24 to 214bpm. It's a bit off an odd thing compared to other parameter types, but will certainly get my attention when I arrive at refactoring the parameter system.

Frequency Table Read for Alternative Tuning
#11

that would be fantastic to say the least!!!!

#12

this is actually a good question for @johannes
why do the oscillators take pitch, rather than frequency (actually a phase inc) ... as taking pitch requires an motf internally, so potentially if your feeding many oscillators with the same pitch its not efficient...
(I'm guessing the answer is perhaps due to g2 , or just ease of use?!)

#13

There are several reasons involved in this equation:
* Oscillators can be ill-defined or even numerically explode at 0Hz, which you'll get if you leave the frequency input unconnected.
* Multiplying the phase increment (or linear frequency) value to create higher frequency intervals can overflow numerically, creating aliases rather than harmonics, while addition on pitch value can be clipped to nyquist. Pure data will produce the alias frequencies.
* The nord modular (before G2) had "master" and "slave" oscillators where the connection in between was the phase increment. This was removed in the G2, I don't know why. Some bits of padding on the phase increment can protect against the overflow mentioned above.
* Linear frequency scaling is very untamed when you can "connect almost anything to anything"
* User experience: create an oscillator and it will make an audible sound. Otherwise you'd need to teach users to insert a mtof object before nearly every oscillator.
In terms of modularity it would be nicer if the primitive oscillator objects would be linear, and the oscillators with a chromatic pitch parameter subpatches with mtof and the corresponding linear oscillator. Future work...

#14

let me try to address some of your points, from my (musicians) point of view.

nice! will the axoloti freeze on them? what sound do they make, glitchy garbage?? i like!! the point i'm making is, let the user decide as much as possible, some of us want the nastiest sounds possible, i can tell you that. for me, the cymatics demo is sonically the most interesting demo of yours, seriously! not to say the others are not nice sounding, they are, but the cymatics thingy was something i never heard, hence my ear is interested :slight_smile:

same here really, i like those aliased sounds in puredata for some things, otherwise i just don't go over the frequencies that sound good. again it should be a user decision, what somebody dislikes can be beatiful for someone else.

i think you underestimate your userbase here, most people come from another patching language, no? i think the barrier to "learn" axoloti is already quite high for a newbie, so this would not matter i think.

there are other examples going into the same direction, why are ahd attacks and decay only going down to 2.41 ms? to prevent clicks? we LOVE clicks sometimes, otherwise we just make the attack a bit longer (e.g. 2.41ms) :slight_smile:

so, all a bit exaggerated but you get the idea...

#15

At 0Hz, for example a differentiated-parabolic-wave type oscillator in floating point would divide frequency, at 0Hz this results in a Not-A-Number, further algorithms connected to that, if they're recursive, would keep recirculating the NaN forever, every float operation with NaN as operand will produce another NaN. Unless the NaN is specifically detected and zapped. This specific (cherry picked) case is not really sonically interesting.
So designing an algorithm often some sort of needs bound operating conditions. Exceeding those can result in unexpected but happy accidents, I do get your point, but it may also result in a confusing user experience.

I've been wondering why no one has made a Eurorack power supply with a CV-in for the supply voltage and output impedance. Some modules may sound really interesting when over- or under-volting, or when the supply voltage starts oscillating with the modules. Or how about power-supply-FM? Or maybe you get a fantastic one-shot pulse sound right before some module's magic smoke escapes when overvolting :slight_smile:
Or maybe a specific eurorack "magic smoke one-shot pulse" module, with a replaceable transistor on the front plate, sold together with a collection of ultra-rare selected new-old-stock transistors :slight_smile:

but perhaps tagged/labeled/categorized as "untamed" somehow.

If you're into glitch, check hellcore's bytebeats

Not necessarily, I believe there are quite a number of users without background in pd or max, pretty diverse.

The 2.4 ms lower limit on envelopes comes from scaling the parameters in semitones, and finding a reasonable balance covering 128/12 octaves. The G2 had a button next to lfo speed parameters to switch the parameter range between sub, low, high and bpm. I consider implementing something similar, but this requires deep modifications.

#16

well given that this could not only be a sonic trip to hell but also a visual and olfactory party, i would implement this idea/sketch as soon as possible :wink: 3d eurorack module!

that said, the NaN is of course an argument, and thanks for your other explanations. also the ahd/adsr is not really an issue, i've been using hd generators with great success, since i often want "instant" on sounds. all good. implementing "speed switches" sounds great though.

#17

may i suggest one thing here? i would skip the khz option all together and make every unit distinguishable with only one letter, that's faster to type. (h = hertz, m = midi, etc.)
i would also let the user set a default unit (globally) that does not need any suffix. (hence my suggestion for the m suffix for the now default values)

#18

Hi,

So I know johannes has said he will fix this himself properly in future, but for the time being, this is a major itch of mine.

My intention is to extend NativeToReal so implementations can do the reverse transformation, too, turning a string into a -64 to 64 Frac32. I'll then modify DialComponent so that it accepts more keystrokes for filling the keyboard buffer. Upon hitting enter, if the string to float conversion raises an exception, it will then try the registered converters to see if one of them can handle it, and set the value to the returned value.

I'll be the first to admit this is a bit of a dirty hack, but can anyone see why this wouldn't work, and would there be any interest in having it contributed?

#19

I think what you're describing is a fine hack, I'd certainly welcome a git pull request for this!

#20

So I've got an implementation of this put together, but I'm having a little trouble finding instances of all the converters, in order to ensure they all work properly? Some of them appear to be for wire connections, and not dials?

Thanks!

Lisa