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, view it on GitHub, or mute the thread.