> I've been running into a couple unrelated crashes while testing this, so for
> now you just get a few preliminary comments without thorough code review:
Ok, so here are a few preliminary comments.
> Please prefix all commit entries, you have "TODO++" entries that miss a
> prefix. Use git rebase -i master on your branch and 'r' to reword an old
> commit.
Yes, having TODO++ without prefix is a history bug. Fixed.
> I've plugged the Unison plugin into Partymonster, instead of XTalStrings.
> Whenever I transpose to -12 or -24, I get a lot of noise (with limited
> unison, 5 voices or so). Is that b/c transposition makes things louder and
> stuff starts to clip, or is there anything else at play for transposing down?
I haven't been able to reproduce this issue, and I am not aware that there is
an issue here. Could you provide me with a more or less minimal test case as
.bse?
Clipping could of course be a problem, if bleposc would be louder than
XTalStrings on average.
> "Fine Tune" lacks a slider.
Ok, I copied the param spec flags from standard osc, now we have a slider. I
don't know what ":f" is, but if standard osc has it, its probably ok in blep
osc, too.
> Where's the "Sync" (or for XTalStrings "Trigger") input? That's so the osc
> starts its phase on a note-on. Or is "Sync Mod In" wrongly named?
There is no sync input because this doesn't make sense. Sync is done internally
in the oscillator, so setting the sync property will sync all unison subvoices
at the right point in time. With unison, resetting all phases at the same time
will make sync produce the wrong result, because then all unison voices would
have more or less the same phase, but we need them to shift their phase to get
the "unison" effect work.
Also note that we need to sync unison voices at subsample boundaries, to avoid
aliasing. This means: we not only to know "sync now", as in sync == 0 and sync
== 1 in the standard osc, but we would need to know how far between two samples
the actual phase reset should be done. This is also the reason why standard osc
+ sync will sound wrong (i.e. you should not use this standard osc feature if
you want to avoid aliasing).
"Sync Mod In" modulates the sync property. So if you set sync to 42, and then
use sync mod + sync mod in, it will change the value of sync, i.e allows you to
have sync change smoothely between 32 and 52, without aliasing.
The oscillator resets its phase in the reset() method. For unison we randomize
start phases, which will sound a little different each time the note is played,
but this is what we want (resetting all phases to zero for unison would sound
more loud at the start of each note, because the sub voices would not partially
cancel out).
> I'm not sure I can sense a change in the sound when tweaking "Shape", is it
> possible that soe of the other settings can render it insignificant?
There are cases where settings are rendered insignificant. Example: If you use
Shape == 0, the result will be a saw wave. If you change pulse width in this
case, nothing will happen, because you don't have a pulse. If you use Shape !=
0, the waveform will be more or less pulseish, and then the pulse width should
be audible.
Changing shape should always result in audible differences though, regardless
of any other setting.
> I find all the sliders hard to use w/o a graphical curve display.
Yes, its also hard to teach others how to use the sliders without the graphical
curve display, for instance in a screencast. I've thought of how to do it,
without this waveform display. I could use my python plotting tool side by side
with beast. Another alternative would be using some LV2 plugin (oscilloscope),
and show the waveform there, while using beast -> jack -> carla with the LV2
plugin.
> Yes, we totally need a stereo-amp now! ;-)
Right. An a stereo filter. And ideally some way to mix two stereo signals into
one, so you could use two bleposcs and one mix% that is between 0% (only first
bleposc), 100% (only second bleposc) and something in between.
These should have per sample mix input, so you can use an envelope to modulate
the mix%.
Also note that currently bleposc doesn't do any panning. Certainly panning one
of the bleposcs more to the left and the other more to the right (with
envelopes modulating these pannings) would be nice. None of these is a
show-stopper for shipping the bleposc as it is, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/29#issuecomment-368361550___
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast
