Now it supports a simple envelope using attack, decay1, sustain, and
release from the GIG file. I couldn't figure out what amplitude it
should go to after decay2 (if set), so currently that is unused.
It would segfault if you had notes being played and then switched the
instrument since the samples no longer exited. Now it'll delete all
notes when you switch GIG files.
Since libgig can't really be used in a multithreaded way unless it was
somewhat rewritten, just use a separate instance of the file for each
new GIG file regardless of if we already have one open in the current
file. Since it's fast now, you can easily have quite a few very large
GIG files open and still have low latency.
Also removed C++11 requirement since I no longer need a move
constructor.
Now, when you press a note, it won't have to load the entire sample into
memory before playing the note. This means that now you can play many
more notes without it glitching. Frequently, the entire note sample
isn't played, so before there was a lot of wasted processing time
converting the sample into float and doing sample rate conversions if
needed.
Also, perform sample rate conversion on the final rendered-out version
of all the combined notes for a period. This drastically decreases
processing time.
Note: currently having more than one instance causes glitching
Now it doesn't appear to segfault when multiple references to the same
instance try accessing samples at the same time. In libgig it said I
just have to create another decompression buffer for each thread. This
doesn't quite make the whole addNotes function thread safe since I still
hear missing notes. But, it's getting closer.
Previously if you created a second instance of a certain GIG file, it
would set the name to an empty string since it didn't create a new
instance, only increased a reference count. Though, it still seg faults
eventually when the reference count is greater than one.
Hopefully the separate mutex for playing the samples reduces the
glitching. Deleting notes after fading out instead of after the entire
sample finished playing (with many zeros after the fade out) will reduce
the number of notes playing at the same time which should allow for more
actually-heard notes to be played.
Also, moved delete note code from release function into the rendering
the notes to the output function. This seemed to fix notes occasionally
not being released.
This makes it sound better than before, so that pianos fade out like
expected and synths abruptly stop as intended. It's not the fully
implemented ADSR of the format, but it's better.
Support for 24-bit samples. It just so happens that the only GIG file I
have that is 24-bit also has the key changing dimension set, so I
implemented that so I could compare the output sound with that of Linux
Sampler. It still sounds different, brighter in LMMS. Not sure if that
has to do with gain, ADSR, or incorrect 24-bit decoding. I'm guessing
ADSR.
There were many crashing issues when playing notes when changing
patches/instruments. More locking, less crashing. However, this also
means that it is quite slow when playing a lot of notes with large
samples and converting sample rates. Linux Sampler amazingly can handle
36 or so keys being pressed at once whereas LMMS nowhere near that many
at the moment.
An initial implementation of playing release samples on key up. It seems
a bit messy at the moment. Wrote a move constructor since there's quite
a bit of passing around the gigNote class. Use attenuation so that notes
set their gain properly based on the information in the GIG file,
quite noticeable on some release samples.
Note that to support move constructors I enabled building the plugin
with the C++11 standard.
Fixed crashes when loading invalid file, but this required exceptions
since libgig throws exceptions, hence the changes to CMakeLists.txt.
If the sample rate is changed (e.g. on exporting at 48k when the samples
are at 44.1k), when playing the note convert each note individually to
the correct sample rate instead of converting the output from the notes
to the correct sample rate.
Save the instrument so we don't have to search the entire GIG file every
time we play a note. This should make it work better on computers that
don't have tons of RAM.
Currently there is a 0.5 second fade out time when the note is released.
I still have to implement the release-triggered samples.
It currently loads 16-bit mono and stereo GIG files. It plays the whole
note (no attack/delay/release), doesn't resample when exporting as a
different sample rate, and it doesn't do anything different based on
velocity.
Add treshold knob to peak controller
This causes the peak controller to react only when the measured peaks are above the set treshold
Might be useful for finetuning your sidechains
Samplebuffer: reload all samples when samplerate changes. This is because of the way LMMS uses samples: we always resample all samples t$
LadspaEffect: some safeguards for the non-inplacebroken plugins which use the same buffer for input and output. Theoretically, if some p$
FxMixer: fix effect processing in multichannel-chains
Well, this commit got a bit out of hand, what with 26 files changed. Oh well.
Basically, we're using the buffermanager to dispense temporary buffers for playhandles and audioports to use.
This allows us to change the way playhandles work. Earlier, playhandles of the same track were waiting in line
to push their output to the audioport. This was of course inefficient, so now they just register themselves to the port,
then the port handles mixing the buffers.
Caveat: this is still a work in progress, the vol/pan knobs on instruments are temporarily non-functional - will be fixed in
the next commit, but I have to get some sleep now.
I don't think we currently have any that would support this functionality, but in case someone has a LADSPA plugin that has audiorate control ports, this allows them to be used with the new sample-exact models
Again... not strictly related to memory management, but since I was in that part of the codebase already...
