the same path and filenames works for me. make sure the filenames in the .wavs file have only a LF or CRLF after, no spaces or anything else. the code will read each line in the .wavs file as a wave which is supposed to be loaded. each whole line is copied as the filename. if you put some spaces before or after the filenames you'll get a bad path like "C:/dir/ filename.wav", or "C:/dir/filename.wav ". maybe the code should strip leading and trailing whitespace, but it's better just to write the filenames into the .wavs file correctly.
here is the file which worked for me:
http://xhip.cjb.net/temp/public/1_.wavs
if you're using the pcm stuff grab this version since i found a bug in the last release..
http://xhip.cjb.net/xhip/releases/0/6/1 ... .16.3b.dll
XHip--Please finish your synth!!
-
- KVRian
- 1078 posts since 28 May, 2003 from world
someone summarize this thread please 
I once downloaded this vsti, years ago, and am now afraid to upgrade for fear of loosing backwards functionality in songs using the 'old' version. Maybe nameconvention on paramters has changed so automation in songs is f**ked?
I once downloaded this vsti, years ago, and am now afraid to upgrade for fear of loosing backwards functionality in songs using the 'old' version. Maybe nameconvention on paramters has changed so automation in songs is f**ked?
-
- KVRAF
- 12615 posts since 7 Dec, 2004
jonas, i would be grateful if you could place your old version of the plugin at http://xhip.cjb.net/upload/
i'm quite fascinated to see where xhip has come from and i haven't kept older versions past the oldest i've placed in the 'releases' section. i wish i could have developed such a version system back then.
just keep the old one the way it is, and place the current one with it's version name intact into your vst plugins folder. keep note that you have multiple versions, and before 'upgrading' each time check to make sure i haven't mentioned any incompatibilities.
you really do not need to 'upgrade' xhip unless you want the new features. the current xhip is almost completely different from the one i released four years ago, so you may actually want to treat it as a seperate plugin. don't pass it up though - the quality and number of features have increased significantly, while the stability of the plugin is now 99% perfect. (always leave 1% for unknown bugs, but i don't know of any at the moment.)
a summary of this thread:
1) feature requests
2) questions and answers
3) ramblings about design choices
4) feature announcements
5) polling for user opinions
6) bug fixes and descriptions of bugs
7) outlines for future plans
8) announcements of things like skinable GUI, requests for coders
9) sharing mp3s and tips, general conversation about xhip
all the stuff you'd think xhip should have it's own kvr forum for.
(i've been saying i should create my own forum on xhip.cjb.net for years, but kvr is just much more accessible to everyone)
http://xhip.cjb.net/temp/public/ranshiz2.mp3
i'm quite fascinated to see where xhip has come from and i haven't kept older versions past the oldest i've placed in the 'releases' section. i wish i could have developed such a version system back then.
just keep the old one the way it is, and place the current one with it's version name intact into your vst plugins folder. keep note that you have multiple versions, and before 'upgrading' each time check to make sure i haven't mentioned any incompatibilities.
you really do not need to 'upgrade' xhip unless you want the new features. the current xhip is almost completely different from the one i released four years ago, so you may actually want to treat it as a seperate plugin. don't pass it up though - the quality and number of features have increased significantly, while the stability of the plugin is now 99% perfect. (always leave 1% for unknown bugs, but i don't know of any at the moment.)
a summary of this thread:
1) feature requests
2) questions and answers
3) ramblings about design choices
4) feature announcements
5) polling for user opinions
6) bug fixes and descriptions of bugs
7) outlines for future plans
8) announcements of things like skinable GUI, requests for coders
9) sharing mp3s and tips, general conversation about xhip
all the stuff you'd think xhip should have it's own kvr forum for.
(i've been saying i should create my own forum on xhip.cjb.net for years, but kvr is just much more accessible to everyone)
http://xhip.cjb.net/temp/public/ranshiz2.mp3
-
- KVRAF
- 7170 posts since 19 Apr, 2002 from Utah
You forgot about the fights with AQ.aciddose wrote:jonas, i would be grateful if you could place your old version of the plugin at http://xhip.cjb.net/upload/
i'm quite fascinated to see where xhip has come from and i haven't kept older versions past the oldest i've placed in the 'releases' section. i wish i could have developed such a version system back then.
just keep the old one the way it is, and place the current one with it's version name intact into your vst plugins folder. keep note that you have multiple versions, and before 'upgrading' each time check to make sure i haven't mentioned any incompatibilities.
you really do not need to 'upgrade' xhip unless you want the new features. the current xhip is almost completely different from the one i released four years ago, so you may actually want to treat it as a seperate plugin. don't pass it up though - the quality and number of features have increased significantly, while the stability of the plugin is now 99% perfect. (always leave 1% for unknown bugs, but i don't know of any at the moment.)
a summary of this thread:
1) feature requests
2) questions and answers
3) ramblings about design choices
4) feature announcements
5) polling for user opinions
6) bug fixes and descriptions of bugs
7) outlines for future plans
announcements of things like skinable GUI, requests for coders
9) sharing mp3s and tips, general conversation about xhip
all the stuff you'd think xhip should have it's own kvr forum for.
(i've been saying i should create my own forum on xhip.cjb.net for years, but kvr is just much more accessible to everyone)
http://xhip.cjb.net/temp/public/ranshiz2.mp3
--Sean
-
- KVRian
- 673 posts since 15 Nov, 2004 from Montevideo, Uruguay
I think this is the oldest one I have:aciddose wrote:i'm quite fascinated to see where xhip has come from and i haven't kept older versions past the oldest i've placed in the 'releases' section.
xhipsynth_beta.dll
-
- KVRAF
- 12615 posts since 7 Dec, 2004
the right click thing is already implemented, i just need to fix it in the gui. the gui handles things like that. i'll let you know when i fix it. (you need to hold ctrl and right click at the moment, i'll make it just plain right-click too)
gsoto; that looks like 0.6.0.0, i've uploaded it to xhip.cjb.net
(very unstable!)
gsoto; that looks like 0.6.0.0, i've uploaded it to xhip.cjb.net
(very unstable!)
-
- KVRist
- 294 posts since 6 Jan, 2005
Ok the thing with right click is that it currently sets most values to -100% as oppose to the OFF position, which is where you need values to be defaulted to.
Not a big issue, but would make an improvement to the speed of workflow imho.
Not a big issue, but would make an improvement to the speed of workflow imho.
-
- KVRian
- 673 posts since 15 Nov, 2004 from Montevideo, Uruguay
Before it's too late, I'm not completely sure if these are related to the synth or the interface, but I'd like two things:aciddose wrote:the synth is now locked down - no more changes to the synth or interfaces. only the gui and control interface may be changed from now on.
- osc b modulations: ability to select smaller values and in general more granularity for smaller values.
- number of unison saws selectable per oscillator, or at least attached to the oscillators' section.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
gsoto:
granularity is 100% related to the gui. it's possible to make it so you can type in an exact value. for now however, the patch format uses bytes for parameters meaning there are only 256 steps available. this won't be possible to change until the new patch format is finished. for just editing the in-memory patches however, floats are used.
the number of oscillators per unison voice issue is possible to change since it isnt a part of the synth at all. the ramp unison feature in fact is not supposed to be there at all. i'm saying: the unison "feature" isnt a feature, it isnt implemented at all. this is only a kludge. it will have to remain the way it is until xhip 2.0 begins, but it is possible to make the kludge bigger and uglier if desired to for example allow "saws" parameters for osc.a and osc.b individually.
(notice that the 'saws' parameter isnt even a registered parameter. it's just a slider that accesses the static value in memory directly without using the interfaces)
djt:
yes, like i said the feature is currently broken. you have no idea the complexity that is involved in fixing it. trust me, it'll be fixed when i get around to it. it's a little bit more complicated than "set to off".
granularity is 100% related to the gui. it's possible to make it so you can type in an exact value. for now however, the patch format uses bytes for parameters meaning there are only 256 steps available. this won't be possible to change until the new patch format is finished. for just editing the in-memory patches however, floats are used.
the number of oscillators per unison voice issue is possible to change since it isnt a part of the synth at all. the ramp unison feature in fact is not supposed to be there at all. i'm saying: the unison "feature" isnt a feature, it isnt implemented at all. this is only a kludge. it will have to remain the way it is until xhip 2.0 begins, but it is possible to make the kludge bigger and uglier if desired to for example allow "saws" parameters for osc.a and osc.b individually.
(notice that the 'saws' parameter isnt even a registered parameter. it's just a slider that accesses the static value in memory directly without using the interfaces)
djt:
yes, like i said the feature is currently broken. you have no idea the complexity that is involved in fixing it. trust me, it'll be fixed when i get around to it. it's a little bit more complicated than "set to off".