New Xhip 0.7 RC1

[aciddose]

http://soundcloud.com/aciddose/flfg
http://soundcloud.com/aciddose/muuzort-miniyurt

someone should make a demo that doesn't suck

[Kingston]

using Xhip 0.7 64bit in cubase 5.5 here.

One rather big problem: is there really no global midi cc save? I can't seem to find it, and it seems the most logical usage for the way the midi cc remap feature currently works.

It's not nice to have to remap +30 controls every single time one calls up a new preset or session.

This is a rather major issue for me at least. Please consider implementing global midi cc save.

Other than that your creation seems to be working well.

[aciddose]

it's on the list.

what you can do is set up your ccs, save the bank (use cubase's menu, save FXB). load this in a new instance. it'll load up 100% of all the settings.

if you do it that way i don't need to implement it.

still though, i want to have a system where you get to adjust the cc as well. for example adjusting velocity curves. that'll almost certainly be in the next version because it's one of the things that bugs me most.

[Kingston]

if you do it that way i don't need to implement it.

Thanks. This works, one extra step when loading an instance. I can live with that, but it's no replacement for a global midi cc map, since the map is always bound to an individual preset in a host. It means another workaround is needed, where I create one "global midi cc" preset, and always use that as a starting point for new patches. Change to a new controller and the preset and all the patches branched from it are void.

[aciddose]

like i said, one of the biggest irks i have with xhip at the moment

[brok landers]

using Xhip 0.7 64bit in cubase 5.5 here.

One rather big problem: is there really no global midi cc save? I can't seem to find it, and it seems the most logical usage for the way the midi cc remap feature currently works.

It's not nice to have to remap +30 controls every single time one calls up a new preset or session.

This is a rather major issue for me at least. Please consider implementing global midi cc save.

Other than that your creation seems to be working well.

wow, look who's here! nice to see you back again...


bugreport:
here the supersaw detuning doesn't work as supposed, the detuning is always resetted, as soon as you turn the knob...

other than that, i'd personally would allow for the osc's to have a higher level into the filter. often i only use one osc, and the level of the input into the filter could be more then, imo... just nitpicking here of course, but that was what my immediate thought was (also on the older versions)...

nice to see you keeping on on it, btw...

[aciddose]

bugreport: here the supersaw detuning doesn't work as supposed, the detuning is always resetted, as soon as you turn the knob...

which knob? the detune amount is width. in order for that not to work, you'd also see the pulse waveform wouldn't let you adjust it's width. is that the case? if so, likely because you've set a midi cc routed to width of the osc which keeps being transmitted.

(the only thing i can think of is that the code is messed up in x64, which i haven't yet tested. why would it be different between x32 and x64? it's 100% float code. possible, but i just don't really see how.)

other than that, i'd personally would allow for the osc's to have a higher level into the filter.

i can adjust it to allow more gain. problem is that it just generates more aliasing.

the saturation control could also have ridiculous amounts of saturation and allow you to generate rather than sine resonance, saw or square resonance. that however would alias way too much

i might experiment but it's safe to assume now that the synth's core features are completely locked. (making it possible to create banks.)

http://xhip.presetexchange.com/temp/aliasing_drive.wav

this file demonstrates:

+12db,
+18,
+24,
+30,
+36.

square wave into lowpass with 50% res.

you should notice: at +12db (the upper limit in the synth) it produces no notable aliasing.
at +18, +24, +30 and +36 the aliasing increases from "very significant" to "slightly more than very significant".

don't think i just arrived at +12db by guesswork or picked a number out of thin air. everything in xhip has a very specific purpose and reason.

[brok landers]

bugreport: here the supersaw detuning doesn't work as supposed, the detuning is always resetted, as soon as you turn the knob...

which knob? the detune amount is width. in order for that not to work, you'd also see the pulse waveform wouldn't let you adjust it's width. is that the case? if so, likely because you've set a midi cc routed to width of the osc which keeps being transmitted.

it does work now, as expected. but i swear it didn't, when i tried the last time. supersaw in the control section was set to full, osc1 was on (osc2 was off), and at first the width wich does the detune did nothing, in both directions. then it suddenly did work, when i didn't move the width knob. but then, when i just moved the knob, it jumped to zero internally, essentially leaving me with the pure ramp. no midi was mapped to any knob, i don't use hardware knobs to control a synth anyway. only with a modmatrix i do use modwheel, aftertouch and pitchwheel, but then as i said, there has to be a modmatrix.
however, it does seem to work now, don't ask me why.

edit:
just now, before i decided to post this, i said to myself "let's duouble check this, before you moan around for actually nothing", and guess what - the bug is there again. but now i think i know how you could maybe check this, too:
- it works with full supersaw count. set it up like this and detune the supersaw to max.
- now decrease the supersaw count to 2. still all good.
- now touch the width knob and just move it a tad - boom, no detuning anymore, and the width knob doesn't do anything anymore.

this is how it happens here. right now, as i post this. maybe this helps you...

other than that, i'd personally would allow for the osc's to have a higher level into the filter.

i can adjust it to allow more gain. problem is that it just generates more aliasing.

the saturation control could also have ridiculous amounts of saturation and allow you to generate rather than sine resonance, saw or square resonance. that however would alias way too much

i think i know why i would want the osc to have more gain. you only saturate the feedbackpath independantly from the whole input, correct? in some synths, when the osc level into the filter cirquit is cranked up, there's also a slight saturation on the osc waveform itself (sometimes a saw is "bent" close to a square wave then, while the resonance, when doing this, gets way less loud at max seting), and it also does tame the whole resonance path... understand what i mean? hard to describe. in essence, the input also determines the ammount of saturation of the whole filter cirquit, not only the resonance itself is saturated... this allows to greatly influence the balance between full resonance and the osc itself and can lead to very fat and meaty sound using only one osc and max resonance.

don't think i just arrived at +12db by guesswork or picked a number out of thin air. everything in xhip has a very specific purpose and reason.

no i never thought this. i was just trying to find a possible way to get the osc's to sound more meaty and thick by slightly saturate them with the whole filter cirquit...

however, i'm having a hard time to assign velocity to whatever parameter. i.e. i tried to allow velocity to modulate the amplitude. so what i did was that i routed it to "amp > volume", but there's just a loud "pop" at every note on, but the sound itself stays at the same volume exept this "pop".
or i tried to modulate the env b amount with it, which was used on the cutoff. but velocity to "filter > env b" didn't do anything...

and a last thing:
you allow for unison, which is just great. but i would love to have the ability to spread the voices in panning (unless this is already possible and i just din't get it). i often would use only 2 voices, but spread them in panning. that would allow for really great stereo unison presets... so i was thinking the following:
when unison is on, the pan knob in the output section could control the spread of the used voices. even counts left and right, if theres an odd count (3,5,7,9), one stays in the center. unless the output pan knob isn't monophonic, that is.
however, this i really miss, and it would be a great benefit. that way the supersaw would be stereo, too...

another thing i miss (unless i just don't get it), is being able to route not only velocity, but also at least modwheel (better aftertouch and pitchbend) to whatever parameter.

and last but not least, what i miss is (unlett i just didn't get thatone, too), to be able to control the rate of the 2 modulators via either of one and the env's...

enough moaning now...

btw, i found out that xhip can do these typical beloved synced-crossmod sounds, think "living on video"-bass... there's not a lot of synths that can do that...


another edit:
please check the random wave in the modulator section - it doesn't seem to do the traditional random wave of other lfo's. iiuc, this wave should output random amplitude at random position, holding each value until the next one is introduced. and the width slider low or highpasses it, to achieve random'n glide... if that is correct (and imo this should correctly be as i describe), then xhip does do that wrong...

[brok landers]

and another thing i noticed:
you're reusing a voice, if a key is pressed 2 times one after another, this prevents possible releases to be played to the end correctly. you imo should allow for a switch to always use new voices at every note on. i know this goes along with higher cpu use, but as one can (thank god) precisely adjust the voice count the preset should use, this would be kinda controllable...

[aciddose]

those are all features that might be interesting. i'm aware of them all for sure.

the lfo random wave - adjust the width. zero width means instant changes. 100% width means smooth slopes. 50% width means the slope only lasts until 50% of the width.

unison - yes, layering and unison are on the list of things todo. will be a xhip 2 feature.

amplitude poping - use the offset to subtract from the parameter. when you use 100% velocity and 0db setting, the result will be +12db. additive, not multiplicative.

voice recycling - yes of course. this is another "flag", i just don't want to add 50 LEDs with text down there. with the "mod matrix" it'll need a "flags/options" section as well.

osc/filter saturation - it just isn't possible. if you clip the waveform it'll start to generate aliasing. the filter is designed so that it does not clip the input signal, ever. at +12db it's just beginning to touch the edge and so you can start to see a little aliasing introduced. that's why when you go to +15 or +18 it suddenly starts to alias completely. (at that point the waveform gets squared off at the edges.)

mod wheel and so on, yes already on the list. "event routing" / "matrix".

controlling rate of the lfo/modulator via envelope or another lfo - not possible. requires a true mod matrix. that's xhip 2.

[aciddose]

right now i'm more concerned with the core (already existing) features.


http://xhip.presetexchange.com/temp/sub_menus.png

i've renamed groups/parameters to make them a lot more clear. now instead of "oscs mod a" it'll say "pitch mod a". instead of "osc a mod a", "width mod a". "osc b mod a", "detune mod a".

that'll make it a lot clearer for beginners to understand what each parameter does.

i'm going to ask branis to create some "group" sections in the background as well (wrap all width controls in osc.a). if it looks any good that'll get included and make an even bigger difference.

the sub-menus for modulation destinations are important for later support of a full mod matrix.

[brok landers]

thought so on most points, however, the voice panning in unison mode should easily be doable, no (i mean, i don't care, i just want to help)?
velocity doesn't work here at all. even with the offset parameter, there's either a loud pop or no reaction when routed to the amplitude.
and i still don't think that the random wave in the modulators do work as expected/as you say above (i understood it correctly, as you write above)... i think it's a bug...
and the supersaw bug is reproducable here.
where can i see which version of xhip i'm using? i don't see anything on the gui...

[aciddose]

when it starts up. it should say xhip 0.7.0.0 (could also check the vst info. most hosts support this somewhere. for example, cubase has a plugins information section.)

i'll be busy all this week so nothing much is going to happen with xhip.

the unison panning thing yes would be fairly easy, it's just a matter of making it configurable. the "super saw" control for example is really stupid because it's just a control that sticks out in the middle of things and isn't really associated with the oscillators directly. i'm not going to do it that way anymore, i'm going to implement things correctly and finish them before i distribute. the old style of posting every little update is definitely not going to happen anymore.

xhip 1 won't have layering/unison/matrix features though. simple as that. xhip 2 will. (doesn't matter how easy it is now, what matters is that xhip 2 will be a commercial product.)

check to see if the x32 version works correctly. the "super saw" bug isn't really important to me, that's just a shit implementation and i'll fix it when i implement it correctly. it's not saved in the presets or anything now so it's sort of useless.

if you're interested in why the bug exists: the detune amounts are "centered" about zero to make sure the average tuning of the super saw remains centered. with any odd number there will still be some amount of detune because i don't move the frequency of the first ramp - it always remains exactly at the set note/etc frequency. when i calculate the average of a single value not counting the original, that results in the detune being set to zero, of course.

so in order to 'fix' the issue the first ramp needs to be included in that calculation and every one needs to have it's own detune value, not just the 15 additional ones. i've added a check "only center if we have at least two" which sort of fixes it, but i'll probably have it implemented correctly in the next release.

a little page/menu to set those options per oscillator, storing them in the preset and applying unison to all waveforms would be better. that's xhip 2 though. i need to draw the line somewhere as i said, the current preset is fixed. i won't be adding anything else to it.

[1-2-Many]

Any slim chance the LimeFlavor skins still work with this? - His were my favorite

[aciddose]

i can try to update those when i have time. they currently do not work, no.

the white one he did didn't have all the controls on it, although it was nice.

in the past we tried that "do it yourself" thing where i gave the tools i use to build the GUIs and nobody really took advantage of that. branis and limeflavor were able to use them to do some tweaking which was cool, but ultimately i still had to do all the programming.

it takes a lot of time and effort.

if i ever implement skinning "scripts" that might make it possible for them to do it completely on their own. for now though things are still mostly in code.