Xhip 8

[ZonderP]

Old thread, I know...
But since I just downloaded the v8.1 alpha version, which is (currently at least) only available as 64 bit, I thought I would also like to check the 'old' 8.0 32 bit version from May 2017.
So I downloaded it from the link provided on KVR (https://www.kvraudio.com/product/xhip-s ... /downloads) and extracted the downloaded zip 'xhip_8_windows.zip'.
The 'xhip_8_64bit.dll' works fine on my Windows 7 machine (as does the new v8.1 alpha 64 bit version),
but I can't load the 'xhip_8_32bit.dll' in none of my 32 bit hosts. (e.g. VSTHost and energyXT). I think it is an access violation error, because a VST scan utility reported error code 3221225477 which is the same as 0xC0000005 which means access violation.

But since I couldn't find any similar bug reports here on KVR, I guess XHip 8 32 normally just should work fine on Windows 7 64 bit?
Anyone had/has a similar issue with XHip 8.0 32 bit?
Or an idea, what could be wrong?

[aciddose]

Old versions of VSTHost and energyXT v1 require the official VST SDK library, which Xhip doesn't use. I did release a few versions with the library way back around ~2006 to allow them to run in energyXT/etc but that's not something I'm willing to do today. Those are simply old and obsolete hosts that don't correctly implement the VST2 'C' interface but read from the c++ object pointers "void *plugin_reserved[2]". This was due to poor documentation of the original SDK header files and these offsets should really be zero-access "private" structure elements from the host point of view.

In other words, those old hosts are attempting to read/access pointer values they shouldn't be. In modern versions of Xhip those are equal to null (0), therefore the access violation reading address 0x0~

100% host-side bugs in old hosts. This was fixed in energy XT v2.

[ZonderP]

Thanks aciddose for the quick reply!

I'm not sure though, if this is the reason in my case.
Because it is energyXT 2 what I use.

And I did some more testing.
E.g.:
* The xhip_8_32bit.dll (V 8 that is) also doesn't work in Bitwig 4.3.4, nor in Cantabile 4.0 Build 3594 (August 2021) nor in MuLab 8.6.24, which are all not that old.

* With the 64 bit version xhip_8_64bit.dll (V 8 that is too!) I do not have any loading problems in 'old' VSTHost 64 bit, nor in Bitwig 4.3.4.

When I find some time, I'll try to debug with my VST scan utility (I wrote it myself).
Maybe I can find out some more details.

Thanks again - and sure - , if you have any other ideas what could be wrong, please let me know!

[ZonderP]

@AcidDose:
I debugged now: On my machine the old XHip v8.0 32 bit crashes immediately when I call the plugins main function.
No chance to give more details, since I can't debug into it.
But it is not that important.
Any chance, that v 8.1 will also be available as 32 bit, once it is out of alpha/beta?

Cheers,
Patrik

[aciddose]

@AcidDose:
I debugged now: On my machine the old XHip v8.0 32 bit crashes immediately when I call the plugins main function.

If it isn't working in any hosts at all that's probably an issue I hadn't noticed back in 2017. The odd thing is both 32-bit and 64-bit versions aren't currently working for me at the moment on my current system, although they both did previously work fine. This makes me suspect the bug is something like incompatibility with a folder path or similar ... ah it's due to the modern alpha init.xhipstate and init.xhippreset formats leading to a crash with the old code.

Go into ~/appdata/roaming/xhip/synth and rename init.xhippreset and init.xhipstate like so, or similar:
alpha_init.xhippreset alpha_init.xhipstate

Both the 32-bit and 64-bit v8 binaries load fine for me afterward. So I would guess it may be a similar issue for you, although why the 64-bit version would work but not the 32-bit version remains unanswered.

I do know there were a few bugs where 64-bit structure packing would automatically make space at the end of structures, but in 32-bit mode reading/copying those words would generate an access violation even though they were never actually used afterward.

Still, the same 32-bit version is working for me at the moment so the cause of the crash is likely specific to something on your system triggering a bug inside the 32-bit Xhip v8.

Any chance, that v 8.1 will also be available as 32 bit, once it is out of alpha/beta?

Yes I can try to compile a 32-bit alpha version and add that to the v8.1 thread's latest post along with the linux 64-bit version. I haven't been testing 32-bit though so it may not work at all. Just compiling/running my libraries in 32-bit triggers a ton of alignment warnings at the moment due to the nature of 32/64 bit pointers and default c++ structure padding.

The alpha version will most likely be more stable than v8 overall, although the two of course aren't backward compatible.

[ZonderP]

... ah it's due to the modern alpha init.xhipstate and init.xhippreset formats leading to a crash with the old code.

This time you nailed it!
Renaming those init files did the trick!
Actually it's only about init.xhipstate.
As soon as I then load the v8.1 alpha 64 bit I need to remember to delete/rename that file again so that I then can successfully load the 32 bit v8.0 version.

Yes I can try to compile a 32-bit alpha version and add that to the v8.1 thread's latest post along with the linux 64-bit version.

That's good news!
Looking forward to test that version.

Thanks!

[raverin]

First of all I want to say many thanks to Aciddose for this great synth. But I found a little problem with "super saw" controller: when I change preset it stands in previous one position. Aciddose, can you fix this bug?

P.S. Sorry for my english! )

[Ah_Dziz]

Hey there. I haven't used Xhip in quite a while. It's always been a really cool synth though. Any chance you've added mts-esp support to it?

[aciddose]

First of all I want to say many thanks to Aciddose for this great synth. But I found a little problem with "super saw" controller: when I change preset it stands in previous one position. Aciddose, can you fix this bug?

Which version is that? The release v8? No I won't fix minor non-crashing bugs like that in v8 anymore (from 2017). Since that time many things have changed which make it a bit difficult to ensure 100% compatibility. Fixing that minor bug might also break the old version completely unless I set up an old compiler on an old OS very carefully to produce the same results. That's unfortunately not worth it for a minor graphical or UI issue.

[aciddose]

Hey there. I haven't used Xhip in quite a while. It's always been a really cool synth though. Any chance you've added mts-esp support to it?

No I haven't looked into such things. I'd like to move to CLAP in the future and so old hosts will stop working completely unless you use a wrapper or have a CLAP compatible host. New alpha versions and all future releases will be CLAP-only. I'm not sure about the microtonal support of CLAP or so on, but that's something to be looked at before the release candidate stage which is likely a few more years away.