XHip--Please finish your synth!!
-
- KVRist
- 284 posts since 2 Mar, 2005
btw, is there any usable gui for this synth?
- KVRAF
- 8101 posts since 13 Jan, 2003 from Darkest Kent, UK
I've just installed the 0.6.17.5 release and only get the hosts default gui in ext2. gui file definitely in the same folder as the dll. I think the gui file is smaller than before?
- KVRAF
- 12615 posts since 7 Dec, 2004
works fine for me, i don't know what the problem might be. it should be impossible to mess up.
did http://xhip.cjb.net/xhip/releases/0/6/1 ... 6.17.4.zip work?
did http://xhip.cjb.net/xhip/releases/0/6/1 ... 6.17.4.zip work?
- KVRAF
- 12615 posts since 7 Dec, 2004
well, i don't know, it works for me in sx5 in windows 7 and i've never had any problems, also there is no reason for there ever to be any problems.
the current source code isn't working entirely and i'm not willing to put in the effort to get it up to par with the older versions. without having someone to use the latest version and debug directly on a system known to reliably and repeatably not work it's kind of impossible for me to fix.
oh, one issue might be that the 'skins' are out of date and for a much older version. i'll remove them from the site until i update them i guess. only the branis gui from inside the archive should work.
i'll be happy to recompile skins by request, but i'm not sure they'll be compatible in their current state with anything but the newest version, too.
the current source code isn't working entirely and i'm not willing to put in the effort to get it up to par with the older versions. without having someone to use the latest version and debug directly on a system known to reliably and repeatably not work it's kind of impossible for me to fix.
oh, one issue might be that the 'skins' are out of date and for a much older version. i'll remove them from the site until i update them i guess. only the branis gui from inside the archive should work.
i'll be happy to recompile skins by request, but i'm not sure they'll be compatible in their current state with anything but the newest version, too.
-
- KVRAF
- 9521 posts since 6 Oct, 2004
I seem to recall you needed to take the default gui, name it differently, then drag the Branis gui to that folder, and rename it to whatever the default gui was called. It worked for me.jmp909 wrote:skins (including default) not working in Cubase5 for 17.4, 17.5, 18.0
regards
j
Cheers
- KVRAF
- 12615 posts since 7 Dec, 2004

http://xhip.cjb.net/temp/public/vsthost.exe
i just thought this was cool - it's a built-in default gui for my testing vsthost. the color thing is of course retarded, but it ends up looking kind of fascinating, like little jellies or something.
i've been working on updating the gui code again recently and i might do some more xhip related gui stuff soon.
btw - i want to do a textured version of the knobs and it's already possible, but i can't do it immediately since sleep might be necessary.
-
- KVRist
- 270 posts since 15 Nov, 2000
hi i tried that, (renamed adxhip.x.x.dll to xhip.dll, renamed branis.xhipgui to default.xhipgui but still didn't work. what version of the plugin are you using? if you could point me to a download that works for you, i'd be gratefulglokraw wrote:I seem to recall you needed to take the default gui, name it differently, then drag the Branis gui to that folder, and rename it to whatever the default gui was called. It worked for me.
Cheers
thanks
j
PS sounds great tho aciddose!... just a bit awkward because the parameter names get cutoff by the default cubase slider GUI.
PPS I have it installed in somewhere like
c:\program files\vstplugins\synths\freeware\A-E\aciddose\
don't know if that's a problem
- KVRAF
- 12615 posts since 7 Dec, 2004
try putting it in the root and see if it starts working - that would show a problem with characters like space or hyphen, or maybe the long path.
still though, it seems to work for me.
C:\program files\mozilla\firefox\components\blah blah\winwrhinwr---m89\xhip.dll
you're probably trying to combine the wrong gui and plugin. i didn't version the guis because they're still so "unstable", i consider them still a work in progress and haven't even bothered to do gsoto's design yet. if it's an issue of the latest version (the alpha 0.6.18) not working with the gui in it's archive, that's interesting indeed. i don't know any reason for it not to work, and it seems to work for everybody else with the lack of complaint..
still though, it seems to work for me.
C:\program files\mozilla\firefox\components\blah blah\winwrhinwr---m89\xhip.dll
you're probably trying to combine the wrong gui and plugin. i didn't version the guis because they're still so "unstable", i consider them still a work in progress and haven't even bothered to do gsoto's design yet. if it's an issue of the latest version (the alpha 0.6.18) not working with the gui in it's archive, that's interesting indeed. i don't know any reason for it not to work, and it seems to work for everybody else with the lack of complaint..
- KVRAF
- 12615 posts since 7 Dec, 2004
over the last weekend i re-wrote parts of my gui engine to make it a true layered system. the disadvantages are numerous with consideration to cpu efficiency, but this isn't such an issue when the system over-all takes a minimal amount in the first place.
there is severe over-draw now, and in addition to that all operations must be clipped to a destination rectangle. this means any drawing functions which cannot clip must use a back-buffer for rendering, and follow that up with a clipped blit to the display buffer. while this sucks for completely real-time drawn images, it isn't an issue for bitmap blits and the previous system required a forced redraw of any overlapped elements to display a new element anyway.
now for the advantages...

a problem with my complex knob object drawn in real time (now sporting shadows, yay...) was that due to the high cpu consumption of the drawing over-draw needed to be minimized. with the old system, a forced redraw occurred when for example a menu appeared and disappeared, or when any element was hidden or shown for any reason. a work-around i used was to store the previous background before drawing into a rectangle for every widget, but this was complex to manage when multiple backgrounds or overlapping elements existed in the layout.
with the new system, only the dirty rectangle is drawn to the screen, and while any over-lapping element is redrawn entirely (if it is required to draw into the back-buffer) this is better than the old system because only directly over-lapping sections need to be redrawn. the old system, again, might need to force the entire screen to be redrawn when a menu popped up and then back out, but now we're saved from that.
it will be, to say the least, difficult to update the branis gui with the new system but i hopefully should be able to manage that over a couple more weekends.
mostly an exercise in pointlessness, but that's what xhip is all about
it'll be much better now though, honest!

after the branis gui is working most of the way again, i want to do my own "super awesome (TM)" gui, and then the new preset format and chunk support to get xhip into a realistically functional state again.
there is severe over-draw now, and in addition to that all operations must be clipped to a destination rectangle. this means any drawing functions which cannot clip must use a back-buffer for rendering, and follow that up with a clipped blit to the display buffer. while this sucks for completely real-time drawn images, it isn't an issue for bitmap blits and the previous system required a forced redraw of any overlapped elements to display a new element anyway.
now for the advantages...

a problem with my complex knob object drawn in real time (now sporting shadows, yay...) was that due to the high cpu consumption of the drawing over-draw needed to be minimized. with the old system, a forced redraw occurred when for example a menu appeared and disappeared, or when any element was hidden or shown for any reason. a work-around i used was to store the previous background before drawing into a rectangle for every widget, but this was complex to manage when multiple backgrounds or overlapping elements existed in the layout.
with the new system, only the dirty rectangle is drawn to the screen, and while any over-lapping element is redrawn entirely (if it is required to draw into the back-buffer) this is better than the old system because only directly over-lapping sections need to be redrawn. the old system, again, might need to force the entire screen to be redrawn when a menu popped up and then back out, but now we're saved from that.
it will be, to say the least, difficult to update the branis gui with the new system but i hopefully should be able to manage that over a couple more weekends.
mostly an exercise in pointlessness, but that's what xhip is all about
it'll be much better now though, honest!
after the branis gui is working most of the way again, i want to do my own "super awesome (TM)" gui, and then the new preset format and chunk support to get xhip into a realistically functional state again.
- KVRAF
- 12615 posts since 7 Dec, 2004
my understanding of this ban issue is that it was a misunderstanding of multiple accounts sourced at the same IP. i'm sure if there wasn't any other justification for it the best way to deal with it would be to ask someone to communicate for you, or (isn't it just that you can't access the forum, but can message?) you could contact the admin yourself and explain the issues.
creating several new accounts is probably not the best course of action.
i do find it hard to believe that you'd get a ban for a few accounts if they weren't used for trolling, so it seems like there is something missing from the picture here...
regarding xhip, yeah i'd also rather get the synth finished. the issue is that if i started working on other stuff now it would be either without any gui or with a buggy one. the preset stuff needs reworking (as on my todo list for a year now..) to get chunks working so everything saves in projects correctly. the interface to the synth needs to be improved also so that i can do this mod-matrix stuff. i started on that last year but only got as far as converting the internals to float and clipping the results, but not actually adding the modulation to the preset values.
the "finishing xhip" would go in between "getting a gui working again" and "super ultra turbo plus alpha edition gui".
edit: this might not be 100% clear because i seem to contradict myself. i mean i'll lay out a very simple gui that i can use to test the new features since branis' gui would be more difficult for me to work with while adding the modulation stuff. i'm even considering not fixing that one until a later point in time and skipping directly ahead to doing my own simple gui just for testing purposes. i won't be adding fancy graphics, making it perfect or tweaking colors and things like that. i'll use the already working gui controls, buttons and other stuff just to get it working and that should take up maybe a day or two at most.
creating several new accounts is probably not the best course of action.
i do find it hard to believe that you'd get a ban for a few accounts if they weren't used for trolling, so it seems like there is something missing from the picture here...
regarding xhip, yeah i'd also rather get the synth finished. the issue is that if i started working on other stuff now it would be either without any gui or with a buggy one. the preset stuff needs reworking (as on my todo list for a year now..) to get chunks working so everything saves in projects correctly. the interface to the synth needs to be improved also so that i can do this mod-matrix stuff. i started on that last year but only got as far as converting the internals to float and clipping the results, but not actually adding the modulation to the preset values.
the "finishing xhip" would go in between "getting a gui working again" and "super ultra turbo plus alpha edition gui".
edit: this might not be 100% clear because i seem to contradict myself. i mean i'll lay out a very simple gui that i can use to test the new features since branis' gui would be more difficult for me to work with while adding the modulation stuff. i'm even considering not fixing that one until a later point in time and skipping directly ahead to doing my own simple gui just for testing purposes. i won't be adding fancy graphics, making it perfect or tweaking colors and things like that. i'll use the already working gui controls, buttons and other stuff just to get it working and that should take up maybe a day or two at most.
-
- KVRian
- 673 posts since 15 Nov, 2004 from Montevideo, Uruguay
How about implementing a very basic modulation matrix for the first version and leaving the routing heaven features for version 2?
It seems like there's still so much work to do. Maybe it's better to start cutting features out and aim for a more short term release.
vsthost.exe segfaults here, but don't mind to debug it, just testing out of curiosity.
It seems like there's still so much work to do. Maybe it's better to start cutting features out and aim for a more short term release.
vsthost.exe segfaults here, but don't mind to debug it, just testing out of curiosity.
