jersmi's picture

@jersmi

Groups

  • Vuo Founder

Compositions

jersmi's picture
jersmi posted a new Discussion, “Audio Filters?

Audio Filters?

jersmi's picture

Finishing a couple thoughts exploring audio tools. Wondering if it would be possible to build an audio filter inside Vuo. Tinkering with the audio tools, having a couple audio filters is a missing link. Be nice to have a 2-pole "state variable" type filter, biquad or otherwise. Low pass/high pass/band pass/notch with frequency/cutoff and Q/resonance. (Shelves would be nice, too). This is a legit feature request, of course, but wondering if possible to put something together with built-in modules?

jersmi's picture

Did a little exploration using Vuo's audio stuff. More interesting than expected!

https://vuo.org/node/2889

jersmi's picture
jersmi posted a new Composition, “Audio Synthesizer

Audio Synthesizer

jersmi's picture

A "modular synth" style setup exploring some of Vuo's audio/soundmaking tools.

Features:

  • Two sets of "oscillators" (detuned)
  • FM operator
  • Modulation (envelopes and LFO's)
  • Sequencer (repeating random)
  • Key/scale note quantizer
  • Wavefolder
  • Vuo's ring modulator
  • "Pan law" crossfader
  • A "placeholder" for visuals

To do: stereo

Composition and supporting files: 

jersmi's picture

I haven't looked at the audio generating capabilities of Vuo, but I assume all standard additive/subtractive synthesis options should be viable.

Only with the most basic stuff, and good luck with that.

I'm a Bidule user from way back, nodes and noodles all the way. Same audio concepts as Reaktor core, except NI/Reaktor's user base and library is vast. I love the noodles.

Anyway, my two cents, in response to the OP:

Step 1: decide on some visual parameters -- for example, luminance/brightness, hue, saturation, R,G,B, alpha, etc. Less headaches if you commit to normalized ranges -- 0 to 1 for all parameters.

Step 2: make some artistic decisions -- for example, what sound parameter does red control? Filter and shape the visual data -- produce good, usable data.

Step 3: set up something in the audio world to receive data from your visual parameters, probably translated to either MIDI or OSC. Both are versatile and powerful.

Go to step 2, repeat.

Let's say luminance to frequency:

  • luminance [0,1]
  • Instead of frequency directly, let's translate to midi note#:
  • luminance * 127 would translate luminance to the full range of note numbers
  • luminance * 24 + 60 would translate to two octaves starting at middle C

Then there are many ways to "quantize" the data to play more meaningful/"musical" notes/combinations.

Besides frequency (or pitch or note number), there are a whole bunch of other audio parameters. For example, there's amplitude (velocity, volume), many shades of timbre (EQ stuff/filters, modulation, waveshaping/distortion), fading between sounds/audio files/samples, selecting some synthesizer preset, things like speed/rate (frequency, but for some other sound shaping thing), or other settings like "thickness", "sparseness", and so on and so forth.

To use an audio/modular synthesis term, I might try to think of luminance as a "modulator" for some parameter -- or more likely some set of audio parameters.

jersmi's picture
jersmi commented on jersmi's Discussion, “3D audio file display

Ok -- success if I convert the 32-bit float .wav to 16-bit integer. Attached zip file includes comp, updated subcomps and .wav files.

Here's what I did to get things working. First thing was to set up some fresh analysis using Terminal:

https://wiki.lazarus.freepascal.org/macOS_Sound_Utilities

Used afinfo on my 32-bit float file:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x00000009) 32-bit little-endian float
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 131072
audio packets: 32768
bit rate: 1411200 bits per second
packet size upper bound: 4
maximum packet size: 4
audio data file offset: 80
optimized
source bit depth: F32
----

Then used Terminal afconvert -f WAVE -d LEI16 to convert it to a 16-bit .wav file. (Just cuz already in terminal and learning these new tools -- assuming could have used any audio software to convert. EDIT: WRONG assumption, see below -- Audacity export is different.)

New file info:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 65536
audio packets: 32768
bit rate: 705600 bits per second
packet size upper bound: 2
maximum packet size: 2
audio data file offset: 4096
optimized
source bit depth: I16
----

Important clue:

audio data file offset: 4096

Essentially this offset value helped solve the issue. I wish I could extract it in Vuo. The number 4096 here apparently relates to the Apple 'FLLR' subchunk -- listed in the Read Wave Header subcomp "File info" readout -- which designates (IIUC) >4k bytes before the audio data "payload" starts.

So I try offsetting the data start byte to 4097 -- works. I also noticed in the Read Wave Header "File info" readout that the "Sub-chunk 2 size" reads 4044 -- related but 52 bytes off -- 44 byte header + 8 bytes? So I tried setting the data start byte to 4045 and that also works. So i am a little confused why both work, still a lot I'm not getting about the numbers.... (Btw, also had to rejigger the Read Wave Header subcomp to properly calculate the data section size, took a minute to get that sorted.)

Finally -- success!!!

Part 2: tried a simple conversion from Audacity, since the export to .wav only exports 16-bit. (I set up a macro -- now I can easily batch convert my 32-bit files to 16-bit). Terminal afinfo shows that it is different from the .wav using Apple's afconvert, the Audacity file is presumably more "universal" (i.e., audacity does not add the "FLLR" chunk and the +4k byte padding -- why oh why would Apple do that...).

And using the data file offset to set the data start byte (to 45) works:

File type ID:   WAVE
Num Tracks:     1
----
Data format:     1 ch,  44100 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 0.743039 sec
audio bytes: 65536
audio packets: 32768
bit rate: 705600 bits per second
packet size upper bound: 2
maximum packet size: 2
audio data file offset: 44
optimized
source bit depth: I16
----

Yet another doc has proved helpful in all this RIFF stuff: https://code.google.com/archive/p/opentx/issues/192 (which originated here: https://stackoverflow.com/questions/6284651/avaudiorecorder-doesnt-write... ).

Notable:

Reading WAVE files properly must really begin as an exercise in locating and identifying RIFF subchunks.

And:

It is allowable to insert subchunks after the data payload.

Which gets back to Steve's point not to trust where chunks are. Case in point, learned today that "acidized" .wav's -- a common format for adding loop metadata readable by audio sampler synths -- put their loop metadata after the audio data "payload".

Finally...

Magneson wrote:

If you're not scared of some heavy nerding, you can also just get the bytes from the wav files via the Data nodes and convert the sample range from the file to the Y-values you need. That way you get straight to the data you want ....

::ROFL:: Well, I guess I'm learning a few things. :-0

(Ps. is drag/drop broken for adding new files to posts?)

Pages