they don't exist atm

i got some free time and will be addressing this today, so they ought to be ready in 24 hours - i've noticed aurora denormals on long releases with a convex curve and have isolated this to the envelopes.. where the #s get real small at the end of the release.

iirc i've since fixed the envelope code, just need to pop it in aurora, dig up the skin and recompile. i would imagine that other vst from the era (standard, maybe naive) use the same envelope.. aurora is the only one i tend to use with long releases.. :p

i'll send a message to emails on file, otherwise pm or message and i'll get it to you.

notification has been sent to my customer database -

vsts affected:
synth pack (aurora, naivelead, standard, w)
water vst
element vst (non-licensed)

because i have included freebies that i don't particularly keep track of with other orders, you may have eg. had some of these items included with another purchase. you're welcome to the updates, but you gotta come and get em pm, email, whatev. please include your email address so i can check and send.

the url for element if you need to download it again is
http://www.xoxos.net/vst/element.zip

uh-oh!

all of these updates were based on an envelope code.. i have since discovered that the fix (denormaling the contour) adds a new error (when pickup is retriggered, the pow functions to convert the release curve to the attack curve weren't liking the denormaled values).

this didn't cause crashes in synthedit but did cause crashes in some hosts.

i believe i have a fix (currently checking for release phase before denormaling) but i want to test it for a while.

this makes my entire synth pack, sifft, element and water vst both currently buggy and thus unuseable, so i assure you this has my full attention.. i just don't want to send out three updates...

i started to use/love Element and mostly Sifft.
outstanding tool.
my only problems so far:

1) i find your new GUIs too small. text is too small and so on.
maybe 30-50% bigger will be good for old eyes
2) i never know what happends inside the plugin.
you dont show much indicators, like where the playhead is inside the sample, whats the value of lfo, what note is playing etc. please add more visual output. even numbers but graphics will be great.

thanks for such deep research and powerful tools.

_waka x / makunouchi bento

i totally agree on the opinion that the GUIs are too small...
would love to see em bigger and actually read what is written there cause i cant find out

i've still got a report of the envelope producing an occasional domain error (sifft thread in dc chat forum includes more info on topic), so not mailing out the fix yet. i will do so as soon as is possible.

until then:

if you are using the synth pack, water, element or sifft, be aware of the error. if you need the update now for a project and the domain error versions of the synths aren't working, i can send you the "denormal during long release" version until there is a fix for both.

apologies :p

thanks rurik!
please post links here when Sifft and Element (and all) are updated.

http://www.xoxos.net/temp/trythis.zip <-- sifft candidate

it looks like this solves the envelope's "pow domain error" issue. i'll wait for more feedback before i update the herd.

sifft and element now updated

owners of synth pack or water vst should have received an update notification.

New Update feb. 16 2013

hopefully you should have been thoroughly harangued via email concerning this matter......

the last update broke the hadsr code used in naive lead and w.. please pm if you have not received links.


there is an underlying issue that started all of this..

the host i use now doesn't have a cpu meter, however during development i become very familiar with how much cpu a particular process uses.

it took a few months for me to observe that aurora was using more cpu than i thought it should be.. i eventually noticed there was a possibility of long releases causing denormaling in the envelope code, leading to my amusing series of updates.. (fixing the denormal caused the sqrt c++ function to behave unusually as it started throwing a sqrt domain error with "really small numbers".. which i've *never* seen before..)

but i do not think this is the issue any more.

occasionally my song projects "gum up" - eg. i'll compose for 1/2 hour then the cpu increases significantly until i reboot. aurora (the interpolated table synth) uses one table for each midi note (if you remember the manual). most table oscs use one table for every 3, 4, 6 or 12 notes (i find 4 and 6 are fairly common), so aurora was intended to be a high quality table osc...

what i suspect is happening is that the large amount of memory used to store the larger table is causing an issue.. i'm not knowledgable enough to know how to address this, i've only observed that sometimes code has a "threshold" eg. using an array becomes less efficient after a certain size because of how the system accesses the data.. afaik..

.. as i only use one host, i'm not sure where the issue lies at all, even if it really is aurora, as i usually have several vst in a project at that point. i'd need to compose with only aurora until the issue showed up to be sure, that could take a while..

no one else has reported it, i use a 1.6g cpu so perhaps the cpu increase isn't noticed by others... or maybe it's jsut my host/system+aurora..

it's a pita issue and i doubt the updates were necessary (as subsequent updates were to fix errors unexpectedly produced by the first update..). i could experiment by recoding aurora to use one table every 2 or 3 notes.. which would change the sound, and be a load of work for shooting in the dark.

fyi

Not yet

New Update feb. 18 2013



thoroughly embarassing. in hundreds of vst, i don't think i've needed to do an update once, except for this, and i've lost count of how many bloody update notices i've sent out...

well!!!!!

somewhere in floating point pachinko, denormaled numbers were never reaching zero.. end result is aurora would run for a while polyphonically, eventually one of the voices catch and before long all eight voices were active but inaudible. it could take a while for this to happen.

i believe i have fixed aurora's issue once and for all (of course, who is going to believe that at this point???). standard and naive use the same code, i think i saw it more with aurora because i use it for pads with long releases.

*before* i send out the update i intend to wait several days. if anyone would like to test it who had a high cpu problem crop up with these vst when no voices are audible, please pm or email.

if anyone (licensed) would like to test aurora, i'm getting significantly better cpu performance here. i'll send the update out in a couple weeks with the new plug.

Could aurora also please get a different colored gui version, please? Please? Baby blue perhaps in addition to baby pink?

I'd like to test it, should I PM you my email?