Looking for sound software for windows

Installation & Configuration Windows
#1

So. I’ve tried alot of software, I’ve tried ardour maybe a couple years ago. it did not suit what I wanted. tbh, no sound software out there today suits what I want. I’ve realized this stems from a simple difference of origins between developers of current sound software and say, programmers, or digital graphics artists.

simply put, someone who got into sound via recording and instruments and soundboards with dials and sliders has a completely different perspective on how sound software should look and be interacted with, than someone who is used to getting and setting values in code and pointing and clicking on vertecies or nodes then using base level actions like scale and translation on nodes or vectors and how that person would design sound software.

I could make some software for myself, but it’d be a chore… and as a game developer and animator, I really should have other focuses than making my own software if even for the only reason that the software given doesn’t compute to my understanding of how it should work from a user interface standpoint.

On that note what I was going to do for such a software is use python’s Wave module to both read from and write to bezier curves. you know with the highs and lows from samples as points on those beziers; simple clickable and movable nodes with handles to control curve progression. essentially selectable bezier curve nodes which can then be scaled on X or Y or both or translated to any XY location and maybe have a location input box like “node1[X 150, Y 3000]” that way I can have precise control over every part of a soundwave and manipulate them to my hearts content before using them as custom vstsamples.
Then have a sequencer window/frame with beziers associated with a VST sample, for things like Volume, Speed, and Tone/Note and those beziers have selectable nodes which can be moved or scaled on XY to allow music and sound composition.

no physical instruments nor microphones needed. I should be able to do everything with a standard mouse and computer keyboard.

but such software does not exist… and as stated it’d be a chore for 1 person to make. so I’m reaching out here, I haven’t tried ardour in years, so, is this a thing in ardour now? or would anyone be willing to spearhead creation of such software? could it be a future UI option in ardour? it could be called a Bezier Mode. what would be the interest level in initiating such an input system? can I count on it’s inclusion eventually?

[tbh I think sound files are written poorly too. they should be written in bezier curves, it’d use a lot less points/data than with 44k samples/second resulting in smaller files. but that’s a Bezier Sound Format. and we don’t need to go that far.]

#2

The requirements you’re describing sound quite similar to MIDI features. I’ve never used MIDI myself so I might be talking bullshit but maybe something worth considering?

#3

People already do this, and it’s called using MIDI. :slight_smile:

And it’s a pain in the ass because manipulating an endless slew of MIDI parameters via a tiny mouse pointer, archaic keyboard, and staring at a glowing, flashing rectangle is more or less completely insane. … And your proposed method sounds -at best- just as difficult.

Sound is ultimately an organic phenomenon/propagation, and I’d suggest embracing that and picking-up a physical instrument instead.

The main, realistic request here would be to at least include bezier-style manipulation in automation lanes throughout Ardour, as opposed to having to manipulate individual automation points to produce a kind of pseudo, quantized ‘curvature’ (-which is currently the case). This I can agree with you on, and having such an ability would probably help speed-up the automation process in general. I believe others have requested this in the past as well.

How could a song -any song- require less data in a hypothetical “Bezier Sound Format” vs how it is now? … Sound (in general) is vastly complicated, and capturing all the curvature via bezier nodes seems unrealistic. … However, if you feel you’ve got a good idea in your head, please don’t listen to doubters like me. By all means feel free to create what you think is superior, and I sincerely hope it works out for you. :+1:

Cheers,
-J

#4

Possibly, but possibly not. It may require thousands of points per second to accurately represent a lot of music at an adequate resolution, and would be computationally extremely heavy, requiring complex polynomial equations to be solved to calculate the amplitude at any point. Even with modern microprocessors, it would probably be impractical on a DAW.

What, I think, you are describing is largely something that belongs in a software instrument, rather than in a DAW. DAWs have a (broadly) specific purpose and, contrary to your claims, that purpose was shaped by decades of musicians and sound engineers who worked on analogue desks, tape machines, and other equipment with knobs and sliders, and much of that capability and workflow has been encapsulated into modern DAWs, including Ardour.

Particularly, DAWs like Mixbus provide capabilities and an interface which inherits from the analogue recording studios of the 60s and 70s.

Back to your “requirement”. This sounds very much like a software instrument, more than a DAW. Something like DIN Is Noise might be what you are looking for:
https://dinisnoise.org/

When it comes to one of the primary roles of a DAW: arranging and mixing recordings, There are plenty of plugins (EQ, compression, etc.) which present knobs and sliders, and if you want to deviate from that there are also plenty which use bezier curves as a user interface (some of the LSP plugins, for example).

I concur!

Cheers,

Keith

#5

it has to do with data sizes. your typical sound sample is 16 bits per sample *44k = 704,000 (687.5kb)/sec (kilobits) (in bytes it’d be 704,000/8/1024 = 85.9375 Kilobytes/second)

beziers however would have the following information for sound:
{pointnumber: [[location X, Y], [lefthandle X, Y], [righthandle X, Y], Linkage(what point number comes before it that it connects to (if any))]}
so 8 data sets per point, Y would be 16 bit, point number would likely be increasing in bits as necessary with no cieling starting at 1 bit and moving up depending on how long the sound is. X would also be increasing in bits, linkage would be the same as the previous point number. (tbh point number and linkage could be removed, they’d only be necessary in an editor(save file), in a playable sound file, it’d be one contiguous wave, no need for separate waves, thus no point denotation)

the catch is the difference between samples per wave segment versus bezier points per wave segment., bezier points would be 2(8 or 6 data sets). whereas in all liklihood samples over the same curve might be far higher than 28, lets say there’s 2000 waves per second 44k/2000 = 22 samples per curve each at 16 bits 22x16= 352bits(687.5kbits/sec), where as 2 nodes would cost roughly 8216= 256bits(500kbits/sec). where as without point numbers and linkage 6216 = 192bits(375kbits/sec) so beziers can represent sound with close to half the data size that samples can (roughly, it depends on if you’re going to exceed a certain X location greater than 16 bits (65,536))

(tbh now that I think about it, waves are typically evenly spaced in length regardless varying height. length determines speed the sound progresses at (and there is a minimum) so a simple speed denotation in each node could replace X, where X was a variable length in bits based on progression, speed would probably suffice with 8bits as that could represent 256 speeds, and only the node itself needs a speed, so the dataset could be even smaller like [[speed(8bit)], [Location Y (16 bit)], [left handle offset% 0.000 to 1.000 (16bit), left handle Y (16 bit)], [right handle offset% 0.000 to 1.000 (16 bit), right handle Y (16 bit)]], making each node the same amount in bittage at 88bit per node, *2 = 176bits per curve 2000/1024 = 343.75kbit/sec (1762000/8/1024 = 42.96875 Kilobytes/sec).
you could get even craftier by only using speed on the timeline not the nodes so speed then becomes an optional parameter which is included only as needed reducing most nodes by 8bits in size.

tracing a bezier to determine it’s Y at any given X is simple trigonometry, computers do this really fast today, it does not require a lot of resources and can be done in real-time.

this is roughly the data science behind why sound would take up less space in a file as a bezier curve.

#6

midi blocks like in midimaker have limitations for example once you start a midi sound on a note you cannot change the note over progression without restarting the vst sound at each change. it does not curve fluidly. you also cannot control volume on a per block or per time basis.

meanwhile the actual vst in question (the soundwave that represents that instrument) is rarely modifiable except in pitch, tone and treble so modifying it so that the sound loops, or modifying the wave to change the sound entirely at given points is not permitted.

so while vaguely similar, midi does not comprise what I’m looking for. (I’ve tried it extensively, the closest I came to a working option was tuxguitar, but it was painstaking to write music in it. one mistake and there was no real undo, you’d have to rewrite a good portion of it, it was restrictive on speed as well, the whole song had to play at one tempo, so no sudden speedups or slowdowns., that and everything was in notes, so if you wanted a sound to last longer than one whole note? too bad.)

#7

I actually had a theory at one point that it would be better to write sound in mathematical formula than discrete points, but a couple of things changed my mind.

  1. And I was aware of this, I can recreate EXACTLY the sound recorded from discrete points via the Nyquist Theorem. There are limitations in terms of sample rate, and frequency reproduced, but it can more than cover human hearing with what is close to commodity hardware these days.
  2. And the bigger aspect, is that while you might be correct in terms of simple waveforms, music is not simple waveforms (And general sound is not simple waveforms). And the more complex the signal the more complex the formula, and it quickly breaks down and gets far less efficient when talking about moderately complex signals and the waveforms drawn from them. As a result, essentially the more complex you get, you need far more complex formula to describe it (Or curves in your case) and get far less efficient with it.

Honestly DSD sampling is not to far off of what you describe in fact, essentially stating whether the curve goes up or down and interpolating it from there, but there is a reason it is not the standard for audio processing at this point as not much is designed to work with it.

Seablade
#8

Hello,
I also dealt with converting the sample into a bezier using various algorithms.
Unfortunately, it is only good for experimental sounds.
You can’t really save all the information, and not to mention that when you restore, you have to cut everything into small pieces and recalculate the time. Not to mention the size of the data, which will be at least double, and you can’t use json or something similar for saving.
But I sometimes use it for experimental sounds :slight_smile:

Here in the picture the Catmull-Rom algorithm with Ramer-Douglas-Peucker point reduction is used.
If there are at least 1/4 of points in the sample, the sound can be recognized.

bezierPlayer
bezierPlayer1080×457 53.9 KB

#9

In the early aughts, an attempt was made to define an audio compression standard based on describing the algorithms used to generate the sound. It was based on something called SAOL (Structured Audio Orchestra Language, which was somewhat similar to CSound) and was backed by a nominally “cross-industry-plus-academic” group. At this point, SAOL is part of MPEG-4 as one of the key components of the MPEG-4 Structured Audio specification.

This provides massively better compression that anything you’re suggesting. However, MPEG-4 Structured Audio is basically dead in the water at this point. Nobody uses it. Data space is not an issue, data bandwidth is not an issue. It’s over.

The other basic problem with your suggestion is the same as with DSD (Delta Sigma Modulation): you can’t edit it in any meaningful way in the time domain without converting it to PCM.

Basically, nobody cares about reducing the space taking up by audio when using a DAW at this point in time. Sure, compression techniques still play a role in the distribution of recorded music, but nobody (who knew what they were doing) ever worked in a compressed format while recording/editing/mixing/mastering, and things have only made that even more trivial to do today.

#10

That would be roughly comparable to FLAC (lossless encoding). I think other lossless compression is similar (wavpack, apple lossless, etc.).
It is not obvious to me whether the bezier encoding described would be lossless or not, but since mature lossless formats already achieve the same space savings there would need to be some large advantage to bother.

Difficult to know what you are referencing without a link, but it sounds like you are describing limitations in specific software, not anything inherent in the MIDI standard.

You seem to be mixing up a lot of concepts and using incorrect terminology, so a little difficult to follow your argument.

A VST is a particular type of software plugin (i.e. software meant to be loaded and run in-process of another application). A sound used for a particular instrument is typically referred to as a sample (the raw audio data), or a soundfont (although properly soundfont is just one particular file format that could be used) which includes the audio data as well as other parameters.

That completely depends on the software in use.

Looping is the most common operation, samplers have been doing that since the 1980’s. I’m not sure what software you have been using that is so limited it doesn’t let you sent loop points in samples.
And morphing or fading between different samples also seems like a pretty common feature.
Perhaps you just need to find better software instruments.

You have been describing audio manipulation features, which is not related to MIDI at all.
MIDI is a communication protocol that is inspired in large part by traditional keyboard instruments. The most basic operations are indicating when a particular note starts and the intensity associated with that note on (“velocity” in MIDI terminology, indicating how quickly you pressed a key on a keyboard instrument), and when that note stops being pressed.
A particular instrument is free to associate the note on/note off information as appropriate, there is no direct mapping to audio behavior.

You list a lot of limitations of one particular piece of software which was developed for notating guitar scores, but that is pretty far removed from the limits of what is capable using MIDI. Much better MIDI sequencing software exists. TuxGuitar is so specifically optimized just for printing guitar tablature scores that I’m a little mystified why you would use that as an example of MIDI editing software. As you point out is is missing very basic features like tempo changes that Ardour has, and if you are correct that it limits note lengths then that is also a quirk of that software and has nothing to do with inherent capabilities of MIDI.

And of course you can have electronic composition software which does not use MIDI directly (for example CSound is one approach), although that does isolate you from the wider ecosystem of standardized instrument plugins which expect MIDI input data.