vm.Synth was used only in a few places, reduce the number of
exported functions. Also, if we ever add some global configuration
to GoSynther e.g. samplerate, we have a mechanism to do so, instead
of the Synth function.
ConstructPatterns was never used except during compilation, so it
makes sense to have it closer where it is used. We could consider
making it even private function, as the pattern table construction
is quite specific to how compiler compiles and probably not that
reusable elsewhere.
The Render name misleading as it did not do the same thing as normal
Synth.Render, because it disregarded time limits. Conceptually, as
the function modifies the state of the synth, it would be better to
be synth.Fill(audioBuffer), but we cannot define methods on
interfaces; therefore, it is audioBuffer.Fill(synth) now.
The VMs now release all envelopes by default, so this mechanism was
useless / did not actually start them as unreleased even when you
thought they did.
The commands and values were not very good names to what the
byte sequences actually are: opcodes and their operands. In
many other places, we were already calling the byte in the Command
stream as Opcode, so a logical name for a sequence of these is
Opcodes. Values is such a generic name that it's not immediately
clear that this sequence is related to the opcodes. Operands is not
perfect but clearly suggests that this sequence is related to
the Opcodes.
The -er suffix is more idiomatic for single method interfaces, and
the interface is not doing much more than converting the patch to a
synth. Names were updated throughout the project to reflect this
change. In particular, the "Service" in SynthService was not telling
anything helpful.
Throughout sointu, we assume stereo audiobuffers, but were passing
around []float32. This had several issues, including len(buf)/2 and
numSamples*2 type of length conversion in many places. Also, it
caused one bug in a test case, causing it to succeed when it should
have not (the test had +-1 when it should have had +-2). This
refactoring makes it impossible to have odd length buffer issues.
The yaml marshaling and umarshaling seems to allocate a lot of memory. When saving the recovery file, the memory use jumped up by hundreds of megabytes. Switch to using json marshaling for the recovery file, as it does waste memory so badly. Binary marshaling was also an option, but its nice in emergency situations that the user can glance the recovery file and perhaps, with some effort, recover stuff from it. Json is good enough for manual recovery during emergency situations.
The options are stereo, left and right. Similar to oscillator sample settings, if you tamper with these, it starts to show "custom". Used some of the generic features of go1.18, so had to update go.mod to require go1.18.
The "auto" was misleading, as it meant self modulation when targetting a unit within instrument itself and just voice 0 when cross-instrument modulation. This feature changes the "auto" meaning "self" for instruments self-modulating, and "all" voices for cross-instrument modulations. "all" is implemented by compiling a single send into multiple repeated sends, with only the last popping the stack (if necessary).
Closes#107
BREAKING CHANGE: The problem with crush was that it had very few usable values. This changes the crush to map the value nonlinearly, so the crush resolution is bits. Still the upper portion of the values is not very usable (bits 12-24 i.e. hardly any crushing), but at least the lower portion is usable. But now crush resolution has slightly different meaning.
go v1.21 is more strict about giving methods to C.structs and was complaining about "cannot define new methods on non-local type *C.Synth". The solution was a local type alias: type BridgeSynth C.Synth
Using polyphony 2 gave errors: 16 instruments with polyphony 2 + 1 global was a total of 33 voices and gave errors when sointu compiling. User will set anyway polyphony as needed for every instrument, like 1 for most instruments, so just use NumVoices 1 always.
The RPC and sync library mechanisms were removed for now; they never really worked and contained several obvious bugs. Need to consider if syncs are useful at all during the compose time, or just used during intro.
[email protected]
