send me a message and i'll add it. use the msg button.
yes, there is a chance. the way xhip's gui is designed allows for modular guis. in short, in the future there will be multiple guis available and you'll be able to load them as plugins into xhip. someone named gsoto has created a gui design for me and his design will be the first modular gui to be implemented. for examples of his gui see here. see the todo here for my progress toward implementing his gui. i've already created some test guis for xhip, however they're no more useful than the current gui. after gsoto's gui has been completely implemented and beta 0.7.0.0 has been released i will start working on a variety of guis in order to attempt to satisfy everyone's wishes. until that time, please do not bother me with gui requests. you can write down what you want, or create example layouts in images and then email them to me so i can store them away for later.
i have no way of predicting when the first stable release will be made. obviously i'll need to have a stable implementation of all the features i can think of first. if you take a look at the to do list on the site you will see what is currently being worked on. versions are labeled in a format with four sections. version DOT beta DOT alpha DOT revision. regarding a ("version 1.0") release, i'll never be able to predict this. i'll announce when beta testing is opened for that release, and there will be a long process of eliminating bugs with the feature set locked down. i really can not say any more than what will happen, i have no idea when it will happen. regarding questions about 'the next stable version', i can give some general info that will help you figure out the 'how' and 'when' for yourself. referred to as ("release") versions, i'll be going through a short period of beta testing before making a release of a beta version. i should outline the version system here.. revision- a revision is a version during alpha phase ("wip") where only a very minor change is made.
- in order to qualify as minor, the change must not have any effect upon normal operation of the software.
- for example, slightly adjusting a default color value would fall under this category.
alpha- an alpha is a version of the software which contains a change causing incompatible behaviour of the software with previous versions.
- these versions are otherwise known as ("wip") 'work in progress' versions.
- alpha versions are the most frequent type of release.
beta- a beta is a version of the software that can safely be used. backward/forward compatibility is expected in these versions, notwithstanding bugs.
- beta versions are released officially and come in an archive or installer with associated data files.
yes, but like many other things, efforts in that direction are held back by the fact xhip remains incomplete and subject to change. if anyone would like to volunteer to write a manual, a better faq, extra faq entries or even just edit my terrible text (spelling, punctuation, other..) to clean it up, send me a message and i'll get you the data files and instructions for writing in the formats i have.
i'll just copy the existing text from what i've written so far as a place holder for a manual. - left and right click on the background near the sliders will change the page
- holding shift will adjust the slider one increment for every two pixels mouse movement
- holding control and left click will reset a slider to it's default value
there are no official patches. i have made quite a few and others have also. you can try looking in the releases directory to see if any have been uploaded there. some good patch banks will be released with the next official release of xhip.
no, there is not currently a mac version available. i have been looking into emulators so that i can produce a port, but i'll also need a copy of mac-os. i'm not sure about anything related to macs, and that makes it difficult to set up the correct emulation and run the right software to produce the port. if anyone has experience coding vsts on mac, and can tell me how to set up an emulator in order to do it, please message me. once i have a working mac development platform, it will be easy to port everything, and it will get done quickly. i'm not interested in spending any money doing it. if it costs money to develop a mac port, it isnt going to happen any time soon.
first, try to check the faq/to do list to see if it is going to be implemented in the future. it may be that i plan to implement it, but it isnt on the to do/faq. in that case, just send me a message and i'll add it.
i've added a number of parameters than i plan to implement in the future to the interface code, but they have not been implemented in the synthesizer. check the to do list to see some information about which parameters these are, and check my news/blog page for updates. i'll always make a post to the news when a new feature, major bug fix or change to an existing feature is implemented.
it would have to be with x-hip, chip/xhip (ekship), or just X-H-I-P. i never really considered the name when i created it. it was going to be "chip" since the original synth program made only chip sounds. by the time i wrote a vst version, i had gone away from the idea of calling it "acidsynth" and "chipsynth".. and "xhip" came to me. it's x-chip, either ex-chip, or extreme-chip, or "not eXactly -cHIP".
in xhip, i use some terms which are neither "standard" nor common in the field of subtractive synthesis that i feel are more correct than those which are common. the waveform often referred to as saw for example is called "ramp" in xhip. "rectangle" is a term which can be used to represent any polygon of four edges with 90o angles between all edges, including squares. like "rectangle", "ramp" is a broader scoped inclusive term which can be used to represent relaxation-up-ramps (known as "saw"), relaxation-down-ramps, up-down-ramps (known as triangle), or any type of ramp moving in any direction, with any type of behaviour, linear or otherwise. unfortunately it is not practical to allow the oscillator ramp to be shaped between up-ramp, down-ramp and triangle. instead, the audio oscillators offer ramp and triangle individually, where triangle can be shaped between a linear up-down-ramp and a parabolic up-down-ramp, a wave shaped approximate sine. in the modulator section you'll find what are typically referred to as "low frequency oscillators" ("LFO"). the ramp waveform here can be shaped using the duty cycle control which is typically referred to as "pulse width". the rectangle, ramp and sine waveforms in the modulator can all have their duty-cycles adjusted. you'll probably find that i have used names which are not typical in other sections of the synthesizer. i am not always entirely decided upon the most correct term to use and often as i add new functionality the terms used for certain components in xhip will need to be changed in order to remain accurate. if you can not find a feature you expect, try searching for it. you can attempt to ask on a message board where other users of xhip might be present, or you can send me a message through this site. it might be that the functionality you're looking for doesnt exist in xhip, see the "why isnt feature 'f' implemented?" section of this faq.
in xhip i've decided to offer modulation for the pulse width on osc.a, and for the tuning of osc.b. this configuration a majority of the time is not quite as limiting as you might think. by simply reversing which osc you use for which purpose, most of the time you can ignore this limitation. for times when you are limited, for example when you want to module the pulse width of both oscillators at once, there are not many options for you. xhip's cpu requirements are more than 50% based upon modulation routing. one of the main reasons xhip sounds better than a lot of other software synthesizers is the fact xhip applies modulation on a per-sample basis. a majority of other software synthesizers only calculate/apply modulation every chunk of samples, often 16 or 32. some of these interpolate coefficients which have the modulation already applied between chunks. this unfortunately though leads to error in the modulation. often it is not noticeable, but it can sometimes be noticeable as xhip should provide evidence for. since the cost of modulation in xhip is so much higher than in other synthesizers, adding these extra modulations would be very expensive. there is a way to produce pwm on the 2nd osc though. try using osc sync from the first osc to the second and modulate the frequency of the second osc between equal and one octave above the first. this should have the same effect as a pulse width control would. hopefully you wont find these missing features limiting. i do not find them to be any limitation at all. in the future when xhip is optimized more extensively i may consider adding more features. regardless of that, one day there will be a modular version of xhip available where you can apply any type of modulation and consume as much cpu power as you like.
use the 'wav' button to load a wave file and select one of the pcm waveforms in the oscillator waveform section. you can load as many pcm files as you like, but the gui only allows you to access eight of them. if the file is large, a warning will be given. the warning claims an error might occur, but bugs have been detected with equal frequency when not loading large pcm files, so you need not pay too much attention to the warning. bugs have been detected, so you should use the pcm feature carefully. the pcm feature remains classified as alpha.
it isnt! the filter frequency is an offset, it works like this: filter frequency = frequency + keyboard track + modulators + envelopes + frequency mod. so, to make the frequency control 'accurate', you must disable all the other inputs. filter saturation will also change the frequency, especially at high resonance values. this can be a problem when trying to use the filter in self oscillation, tuned correctly to the keyboard. hopefully that problem will be solved in the future. in order to have the filter track the keyboard perfectly, disable all modulation and set the frequency to 130.81hz (C2). you can use the oscillator range control in order to adjust the root frequency of the oscillators independently from the filter. unfortunately, the keyboard tracking on the modulators remains the same in this case. for me though, that has not been a problem. the filter's range is great for pretty much any type of patch.
initially, xhip was just a toy, a few years ago. it did not have the ability to save patches at all. i added patch save and load when i implemented it as a vst, and then added bank functionality when it was requested. i've always wanted to finish xhip completely before making any even remotely "final" patch formats. xhip is currently (wip versions after beta 6) in a state where it does not even save patches which will load correctly with the next release. the basic patches that are currently saved are copies of the internal state kept by xhip's parameter management. the synthesizer, and the notelogic (which implements unison, tuning, glide modes and various other things you see on the control page) are separate objects. in the future, i'll shift control from the synthesizer over to the notelogic, which will save patches containing all parameters, including pcm data and event-parameter routing data like midi cc mapping. this will be implemented as part of the next release version. see the todo list for an impression of what needs to be completed before the next release is made.
no. they will work some time between now and the release of beta 7. the only way to ensure that these files work correctly is to use chunk mode which i have not yet implemented in xhip. due to this, if you save your tracks in your host they possibly will not work with future versions either. for this reason i recommend that you keep the versions of xhip you use in tracks. since i have begun maintaining a version system and an archive of releases this is less important. i'm not sure about fxp files, if i were you i would simply use the patch formats internal to xhip since they are stable and give you better accuracy. in the future additional information will be saved in the patches. see "some of the parameters are not saved in patches, ..."
xhip uses a very fast envelope time when on the lowest setting. try to adjust the time upward to 10ms or so, until the clicking goes away. the clicking is actually very intentional, and a natural behaviour. there is nothing wrong with the synthesizer and it is not something that can or should be fixed. many synthesizers have a much longer minimum envelope time and you may just not be used to the very fast times possible in xhip.
for the source oscs in xhip, the pulse width parameter is currently multifunction. with the pulse waveform it behaves as you'd expect. with the ramp waveform it adjusts the detune on a poly-saw/super-saw of 16 waveforms between 0 and 2 semitones. on the triangle waveform it adjusts between a wave shaping depth of zero and full, where the waveshaper transforms the triangle into an approximate sine. the waveshaper used is the same as used in most analog subtractive synthesizers, this gives a more rich, impure sine. this is intentional. these additional uses of the pulse width parameter are kludges and i hope to find a way to improve this section of the synth/gui in the future.
select ramp waveform and adjust the pulse width setting to change ramp detune. there are by default 16 oscillators, but that can be adjusted to any number from 1-16.
| 