looking for a bit of feedback on synth, please.
also have some questions(see note in zip)

sim-3x v.0.1.33 beta test draft

http://www.box.com/s/eqzb68o54aa287lfz0pp

hi,
10mn test :
- there is something weird : left channel is higher than the right frequently.
- delay/bpm horizontal slider must be moved vertically = bad
- 4% cpu when no sound is played, a bit heavy, unfortunately you
use stock osc without on/off pin, so it's not easy to shutdown it.
(all osc, vcf etc stock SE components should have this option!)

about your DC shift, i have stopped to use the SC_SVF, one of my favorite
filter, but have bug with SE v1.1, maybe...? it's difficult to help you without audio path design. i had this kind of problem when i re-shape the osc
in some cases.

about your 'kill audio engine', depending of your design, but
you can limit the lower range of the res, or put a compressor/
hard limiter after the filter ?

suggestion : a GUI a bit more contrasted/sharp ? think all users
don't have 20yo eyes

globally, it is a cool 'classic' synth

CPU spikes on loading and patch changes are normal. If you think about it, a patch change is the same thing as automating all the controls at the same time. This is bound to cause a momentary spike as all the controls are shifted to their new settings. It doesn't seem to be much off an issue with your synth, the spike is barely noticeable.

Just briefly tried out the inverted envelope problem and I think either something is wired wrong or you have a buggy module somewhere. It's not something we can help you with without looking at the se1 file.

ah, so you spotted the chorus thing that makes one side
higher thah the other. it's my stereo chorus with one side
using inverted cv of the other. been lazy, not looking into
that more, probably a very logical explanation. i'll study
it separately.

and that is why i haven't fixed these things yet: still getting
the whole thing together (it's moved on quite a lot in a more
evolved version)

vertical operation on all those horizontal controls was intentional,
seemed ok to me instead of hunched-shoulder wrenching sideways of
mouse ...comments on contrast noted..bloody 'ell, that's a lot of
graphics to re-do...in fact, i've concluded all GUIs should be quite
big, now: you can always minimise them. better than wrecking your eyes.

the filter thing is just a huge wwwaaaappp from the EG and res'.
there's a point where it kicks in, like a res-generated kick on
a juno or something. can't quite remember what happens with
analogue in this situation, or if they compensated the inverted
side.
i know i need to limit it somewhere when the EG is inverted. again,
i need to work on it separately. negative resonance feedback? just
wondering if there's a standard routine for dealing with this.
i literally send all the EG cv in a negative direction, simple as
that, via inverter. ah...s'pose i could multiply it by -1 instead,
but make it -0.8 or something, scaling, maybe... i'm on it
find the idea of a clipper inelegant, as, bang, it'll hit it's limit
and then there's no range to play with.

i have checked the SC_SVF again, -v confirmed here,
you should try the standard SVF or a DH. I guess the delay will
sleep too when no note will played + dc solved = less cpu when waiting.

"just wondering if there's a standard routine for dealing with this"
i don't know, i put a standard clipper. I suppose the 'overload'
will be different following the VCF used.

i agree with chuck death, the cpu spike should not be a problem in your design. but when there is a ton of knob it is different,
the 'float to volt' have a 30ms fade, i remove it during program change.

what do you mean '-v'? DC offset?
SC SVFx2 is giving me that lower LPF mode that is a bit
like a volume-compensated moog(no volume drop with reso).
already have 2xSVFs on another setting, but nowhere near
same effect. ok, so i didn't try many...lots more out there.
and:
what do you mean by 'removing during program change'? having
it in a container that ignores PC?
question: i have GUI objects in GUI containers, separated from
all the processing modules(these are the ones that normally
'obey' PC). do i really have to think of polyphony settings for
GUI objects? i figure not. just processing module containers?
and that's a whole other story. working it out gradually, but
is it important to set polyphony at each stage in the signal path?
i still take a simplistic approach to this, and don't know what'll
happen with big chords on this. you can just imagine my kb
skills...

nice little synth

i'd lose the scope tho, unless its showing the raw osc output, visually its not much use (and even then its not much use, imo)

"what do you mean '-v'? DC offset?"
yes, a negative volt value

"removing during program change"
i set temporary the fade 'off' : the smooth transition is disable,
i guess decreasing the cpu spike.

"do i really have to think of polyphony settings for GUI objects?"
If no signal coming from a poly midi to cv, a GUI element is 'mono' so
you can containerize it w/o problem

"is it important to set polyphony at each stage in the signal path?"
I use this typical design :
- a mono container with modulators like LFO, mod.wheel etc
- a poly container including VCO, VCF, VCA etc
- a mono container including FX

each container must have a midi to cv with his appropriate setting,
off course if a midi to cv signal is required.

cheers Kriminal! i did remember your 'Kitten''s analog-ness
at some point while making this.

Eric: the clipper solution is not at all 'inelegant', quite
the reverse. i tried my scaled invert this morning, but it
didn't work on all settings. too many variables to work with:
cutoff, reso, env amount, waveform, pitch etc.
there were three test settings full@ x-1, half @x-0.5, and a
median setting i tried at halfway and(???) -0.667(...)(wdf)

i got better results with a clipper, which allows a great deal
of control and tuning of the peak point. still have to find the
optimal setting.

inelegant is a bit like saying i won't use a compressor on any
recording because it will ruin the dynamic range, lol.. am getting
some very nice harmonic stuff-but couldn't really rouse the neighbours
at 5am.

but i'm still a bit untutored on the negative part of the waveform,
and of 'limiting'. i would assume these would have equal significance,
but apparently not. viz the negative voltage issue. explanations
welcomed.

nb: i also felt the scope was superfluous but i thought 'let's have
a look at the pretty waveforms'. i will fix this with no scope, but
this GUI is now stated and dead, moving on. (unless i decide to do
a alesis hr16 orange lcd digi gui thing )

i'll see if i can suss out what you mean about float to volt etc.
thanks for consultation etc

re polyphony: ok, well in fact, i have ALL my GUI objects
in a GUI container+subcontainers, with all the other stuff
outside of it. makes sense, and is very easy to organise.
but polyphony on GUI actions?? probably not. but i've still
allowed for it.

ONLY the GUI container/s respond to PC. almost everything else
is set to ignorePC. now i'm thinking volt2flots could also exist
outside the GUI container as well, with only the float cable
connected(...)> can't remember how much of an issue this is.

'everything else' is the signal/path/cv etc. here, i do try to
do something useful with polyphony(eg: LFO=mono/osc=poly, and
i #think' adsr = poly etc etc)

but fx=mono??? i'm giving that as much whack as i can. in some
situations in the past, my synths have choked in polyphonic
situations, but not yet noticed here. anyway:...onwards...

ok, so it wasn't kitten, but 'Felix' u kno' what i mean...
but i found something more interesting this morning, Krim',
with your Bass Terminal plugin...please tell, what is that sem
called 'voice mute'(or somet'ing) in there? ( in fact, i loaded
it for a completely separate reason: to check if it could do
something the BSrack does - nb: i made a patch of this, and it
hasn't loaded the same way yet)