jimd1989 / delay Goto Github PK

Rather than parsing a normal func like < and an "extended" func like @<, and presumably extended extended funcs like @@<, each with their own enum cases, can probably go the J route and combine them all into one alphabet like <, <.. . isn't used in functions at the moment in order to make parsing decimal numbers dead easy, but the logic of adding it would not be much tougher than the existing @ notation. The only ambiguity would be something like <.5, which should favor the function. There are already certain instances that necessitate whitespace anyway.

Can be combined into one alphabet with something like

VM_LESS_THAN = '<',
VM_FLOOR = '<' | ('.' << 8)

etc.

This would remove the need for redundant f and g fields in the VmCell union, which currently segregate normal functions and extended functions respectively for pattern matching warning purposes.

Rather than having hardcoded parameters, the program should expose variables like volume, feedback, wetness, delay time, etc to the user and allow him to use them to his own ends via a stack-based language that runs in a VM. Much of this work has already been completed in the vm directory, but it hasn't been wired to audio yet.

• The audio program is compiled from plaintext to bytecode once, and then run against every sample of left and right input.
• At the end of a program run for a given sample, the stack should contain two floats: a right sample and left sample, with left on top, since popping will allow access to left first, as is conventional.
• This will yield four floats for each sampling cycle: left/right derived from left input, and left/right derived from right input. These can be mixed down the stereo however one wishes.
• Errors should fail silently and sound should continue at all costs. Glitched audio is half the point of allowing this level of access.

Because the VM is stack based, can make a simple stored function syntax. Because it is compiled, this doesn't require a particularly performant data structure. It will only be relevant the first time a user-defined program is entered, not during audio rendering.

The [ and ] chars are not used at the moment, so they might be good candidates.

Defining

Proposed syntax:[name proc]

For example: [avg +2/].

This would be easy to compile.

1. When a [ is encountered, create a pointer to the next char: the start of name.
2. Insert a null byte at the whitespace.
3. Create a second pointer to the char after the space: the start of proc.
4. Insert a null byte at the ].
5. These two strings are placed in an unordered array of key:value pair structs for retrieval later in the compilation process.
6. Since compilation takes place linearly, it should be possible to redefine a func whenever.

Invoking

Proposed syntax: [name]

For example: 2 4[avg]

1. When a [ is encountered, create a pointer to the next char: the start of name.
2. Read until either a space or a ], and create a null byte at either address.
3. If no space was detected, it is not a function definition. Search linearly through the key:value array doing nothing more than strcmp over the keys.
4. If a match is detected, compile the raw string value to bytecode.
5. This method means recompiling strings every time they are referenced, but it is dead simple.
6. Should work with recursive invocations, like if the definition of avg was +[divTwo].

Program currently reads from hardware determined buffsize for audio input and calculates modulation in the same chunk before outputting. Can use an arbitrary virtual buffer size in between read/write to allow for tighter user input.

See my notes on conditions and loops. Some details may have to change.

Don't even know where to start on this one, but could be a possibility if the bytecode is particularly slow. x86 should be first target. Solutions that require additional dependencies will not be implemented.

OpenBSD's random functions are concerned with cryptographic bullshit that is not needed for audio noise. Look into cheapo RNGs and implement one.

The $ VM procedure should generate a sine value. Most likely from a lookup table, but Chebyshev + Horner might be easy for a stack lang. Need to determine the most convenient phase to operate over, however: [-1,1] vs [-π,π], or something else.