Wow. I fixed the original popping problem fairly easily. Then, I
spent HOURS trying to get rid of the release pop. After several
failed attempts, I came to the following realizations:
It is not worth the trouble to determine the last time a note crosses
the axis (that is, the last time a note's frame = 0). I intended to
truncate the note at this point, but it is a huge hassle.
So, I decided to go with a short 128 frame decay. This was easy to
calculate and it sounds great! Except, there is one problem. We
shouldn't decay a note if the next note is dead. This creates a gap
between the leading note and the dead note. Therefore, the dead note
is only half-dead. :D Half-dead zombie notes... Plus, this
technique doesn't work for keyboard notes or overlapping notes, but
this would have been only part of the solution. I'm using "decay" and
"release" almost interchangeably.
I'm trying to find a way to detect if a note immediately follows
another (edge-to-edge). The code that uses nphs and compares offsets
almost works right, but I'm worried about what happens if the two
notes are on either side of a period. Or, what if the notes are not
adjacent, but it just happens that the second one's offset is less?
Read further, this may not be an issue.
Assuming that I can tell if a note immediately follows another (the
second note in an edge-to-edge pair), and if there is a way to request
extra frames for a release, then I have all of the problems solved.
Actually, I only need to know how to request extra frames. Read
Here is the policy:
1. A standard note is played. When the note is released,
RELEASE_COUNT frames are requested. The VCA fades to 0 during this
period. This decay mimics the 303's original exp. decay. I've wanted
this feature for a while.
2. A non-dead overlapped note is played. The existing note is
detected and we fetch our starting values from saved_states. Since we
just interrupted a note, the first 128 frames are used to fade out the
previous note before we play the new note. There is a chance we
interrupted the previous note's release. If this is true, we still
just fade it in 128 frames; expediting the decay.
3. A dead overlapped note is played. The existing note is detected
and we fetch our starting values from saved_states. However, we do
not want to touch the VCA, since this note is dead. We are done.
4. An edge-to-edge note is played, except for the first one. We use
the first 128 frames to fade out the previous note before playing the
new note. Now, I wonder if this case MAY NEVER EXIST. If every note
requests an additional RELEASE_COUNT frames, then this edge-to-edge
note is actually an overlapping note. Why? Because, this note is
overlapping the previous note's release frames. Therefore,
edge-to-edge notes and overlapping notes are the same thing!!
There is no need to test if a note immediately follows another,
because edge-to-edge notes are handled by the overlapping-note code.
Also, there is no reason to distinguish between the two. So the
nphs/offset code because much simpler.
So: all I need from you is to teach me how to request extra frames for
adding a release. Then, you will get a sweet bass synth from me. :)
It is 2:40AM. I'm going to bed too :)
On 8/4/07, Tobias Doerffel <tobias.doerffel@...> wrote:
> Am Samstag 04 August 2007 22:16:07 schrieb Paul Giblock:
> > I don't know if you got my last email.. Besides, I fixed a few things
> > in the demo song.
> > I have the 302 changes done. (I think). Email me when you have a
> > new version up on SVN. I will download it and test against my new 302
> > code. If everything tests out, then I will commit the changes.
> did you get my last mails a few hours ago about overlapping notes etc.?
> > By the way, here is a cool demo we can include in the next release (At
> > least I think it is cool)
> I just added a bassbooster-effect with freq=60 Hz and ratio=10 to the first
> lb302-track - sounds much better in my opinion (and my subwoofer gets more
> busy ;-)
On 8/5/07, Paul Giblock <pgllama@...> wrote:
> OK, I have the oscillator resuming fine now (for non-overlayed notes).
> However, I noticed a nasty bug that may have been introduced due to
> the recent changes to LMMS. It seems like most generated instruments
> (3xOsc, LB302, etc...) have a nasty pop upon release. Enabling the
> volume envelop with a decay or release seems to fix the problem.
> What did LMMS used to do about the end of a note.. That is, you
> don't want to just leave the sample high and then all of a sudden set
> it back to zero.
> If this doesn't apply to LB302, then how can I request some extra
> frames from LMMS so I can make my own release?
> On 8/5/07, Tobias Doerffel <tobias.doerffel@...> wrote:
> > I'm going to bed now (it's 2.20 AM here) so don't expect any answers to mails
> > in the next 8-9 hours ;-) if you got something working please send it to me
> > or check it into SVN (btw, you should do an svn up, I fixed some stuff) - I
> > wanna see it ;-)
> > toby