New Xhip alpha

[aciddose]

If you can reliably reproduce a problem it is almost definitely a bug.

Even if there is something special about your system, the code should be designed to cope with that. If it leads to a crash I'd like to fix it.

The current revision (r623) should solve all your problems. Can you test that and let me know if you can make it crash?

You can now load a bitmap for the background (it is tiled, no settings yet) by middle clicking on the logo. It's set up to be centered and tiled, and it's multiplied with the other content to allow greyscale images to blend with the color gradients. I support BMP, TGA and JPG although only JFIF is supported, not EXIF so likely images from digital cameras will not load. In those cases just resave the jpg with ms paint or similar and it should load fine.

The scaling is almost perfect also. I've included all the resized bitmaps and I've improved the background scaling code to use cubic interpolation rather than linear. These take a little time to zoom, but they are cached in /program data/xhip/... so it only needs to process them once. I can also reduce the number of widget sizes by scaling the widget strip images, although this stuff is lots of fun I should really focus on the core issues again and fool with this after the RC is finished.

[aciddose]

https://soundcloud.com/xhip/pcm

Had a little bit of buffer underrun there, I guess 64 voices is too many

(Use 4x unison with stereo switch on, a tiny bit of detune not too much.)

http://xhip.net/alpha/releases/presets/Test%20PCM.zip

Now if only I could play some music that wasn't horrible

[donquixote]

Hi,
regarding that switching pcm lists problem (xhip crashed), i was using the 32 bit version, decided to check on the 64 bit version, don´t know if wineskin osx suports or not 64 bit windows programs but wasn´t able to install any.. so i checked xhip 64 bit version under bootcamp running vsthost and it never crashed, worked perfectly.
The 32 bit version in bootcamp, crashed like hell when loading pcm lists. .

[yemski]

Cool sounding synth. If I have the time, I may do a bank for it.

[aciddose]

I've been unable to reproduce any crashes in the 64 bit or 32 bit versions.

https://soundcloud.com/xhip/32bittest

There is nothing "wrong" with the samples you sent or the wavs lists.

My only suspicion is that there may be a bug in handling filenames containing non-ascii characters. Due to the fact I treat filenames as plain ASCII, it should be compatible with utf-8 although I haven't tested this much. I'll need to investigate this more in the future, for now there is nothing much I can do.

Yes, if the filename contains utf-8 or anything other than ascii, the C stdlib functions don't handle it correctly. This however should result in an error message which says "Couldn't locate file" followed by the filename presented by the dialog (usually non-ascii are converted to "?" characters) in the display.

I've been working on getting variable fonts supported. So far there are issues I've been having detecting the baseline for a particular font (from which ascent/descent are calculated) so I can correctly center the text. I'd like this to be fully automatic so it is even possible to select a font inside the GUI and have it apply automatically. I may need to use freetype2, as detecting the baseline may not be possible in a reliable way using Windows' font rasterizer.

http://i.imgur.com/tsHyU4a.jpg

[r1_000]

Great synth accidose! The filter sounds nice and the hard soft choice is really good. I like the look and layout of the gui and preset management is well done. I'm glad you dropped the fx because personally I never use them anyway, and it bugs me knowing they're there in the code taking up resources. I was wondering if the pitch amount sent to the env/lfo is in semitones because it goes to 100 instead of 48 or something? A feature I would like to have added is osc phase reset like in synth1 so when you have both oscillators running the volume is the same every time a new note is played. Also if I was being really picky it would be nice to be able to change the shape of the envelopes. Runs well in ableton 9.2 with windows 7.

[r1_000]

I just figured out the oscillators do reset when I set sync to gate so I really have nothing bad to say about this synth.

[aciddose]

Mutant has wanted to see adjustable envelopes. Unfortunately this won't happen, period. At least not in the sense of adjustable curves as you'd see in some other plugins.

There is a difference in using a linear segment and then applying a "slope" function vs. generating the envelopes using lossy integrators in Xhip exactly as ADSR envelopes are generated with analog circuits.

Applying a slope function is always far more expensive because generating the linear segment is already equal to running the lossy integrator.

With this taken into account as well as behavioral (although minor) differences, I'm unwilling to implement that sort of envelope for Xhip. It isn't very valuable and it is very expensive compared to what we have now. You must consider the fact modulation in Xhip is per-sample, while in software with such adjustable envelopes it is typically at a lower modulation rate.

What I can do however is allow you to modify some parameters of the envelope such as asymptotes (only used for attack currently) and expand its functionality by adding additional sections (peak hold, hold, delay, multi-stage) although the more complex features are a Xhip 2 thing.

Adjustable asymptotes are very similar to allowing the curve to be adjusted. The current value for decay is the maximum curve and asymptote adjustment would allow you to go from that to linear. Inverted curves are too expensive and again, more a Xhip 2 thing.



Remember Xhip is currently 11 years old as a VST. I'd like to finish this before I die of old age.



I haven't dropped the FX, I am undecided as to whether they need to be in the next release or whether I want to include them in presets. I'm more likely to include them now, to be honest. There is no additional cost while they are disabled and there will be a "master disable FX" switch if they are included. I just don't want to delay the next release too much by adding additional work, so if this isn't ready for release it will just be disabled (the section will disappear) and come back in the alpha.



The pitch controls for oscillators and osc.b mod are unfortunately 4 octaves wide (too narrow) and squared. This I would like to change to semitones range as it would be far easier to control. A step starting in cents, then semitones, then octaves would make sense. Perhaps one semitone for the first 8th, then 2/8 to 5/8 to three octaves (36 st), and 6/8 to 8/8 to ten octaves.

Unfortunately that is a bit complicated so I haven't done it yet It is definitely on the list though.



Osc phase sync is also on the list. Currently you can set sync to "gate" which will sync both oscs on note-on.

I can add options for gate + the other sync modes. I'd also like to implement more interesting modes like phase-inversion-sync and soft-sync in the future although not soon.

I really need to get the next version out sooner rather than later, so these things will all be implemented in the alpha after the version 8 release coming after I finish the items currently on the top of the TODO list.

[bassg]

Hello aciddose, I've always liked Xhip, glad to see it still being developed!

Unfortunately, the latest alphas show no GUI in Orion (I think I saw this reported few pages back by other user - I'm on Win7 64 bit SP1, too), works perfectly in REAPER on the same system though.

Orion has been discontinued last year and there's no demo available for download anymore so I think it is going to be difficult to fix it…

Either way - great synth, thanks for your work!

[aciddose]

I've got a copy of the demo, I just need to look at debugging to see if I can fix the issue.


Wayback machine

[bassg]

Oh yes, the wayback machine - I completely forgot about that!

I hope there's something you can do about it. Orion is a neat little host that I am now using almost exclusively for my "song sketching" needs, having Xhip at my disposal would be just great.

[aciddose]

GUI shows fine in Orion demo v8.02 for me, r623 and my current compile.

Some of the following don't matter if it shows on other hosts on same CPU, OS and so on.

• Which version of Windows are you using?
• Does your processor support SSE2, SSE3?
• Does the plugin pass the plugin checker tests on startup?
• Does the window show up?
• What is the content in the window?
• Does the audio portion of the plugin work?
• Can you switch presets using the Orion menu?
• Which version of Orion are you using?

[donquixote]

Hi again, please don´t take this as if i´m insisting on you to look into this, as i told you before, as long as i can load single wav files its fine with me , i´m just testing and informing you on this tests so in the future this can or not be helpful ...

I thought my vista system was 32 bit but it ain´t, its 64 bit ONLY 4 gb ram, so under vista i downloaded vsthost 64 bit version, loaded xhip 64 bit and it also worked just perfect here.
I downloaded vsthost 32 bit, loaded xhip 64 bit jbridged , worked perfect too (loading pcm .wavs). As i told you the xhip 32 bit here on vista crashed a lot like it happen on bootcamp (win pro 8.1) .

Other thing i found was different between the 32 bit and the 64 bit versions was that problem i already report here, when using the 32 bit version and when loading a .wavs file, if i choose the 2nd wave its the 1st wave that is being selected, if i choose the 4rd wave its the 3rd wave that´s being selected and so on... This don´t happen when using xhip 64 bit version, this version works ok in selecting the waves.
thanks.

[bassg]

GUI shows fine in Orion demo v8.02 for me, r623 and my current compile.

Some of the following don't matter if it shows on other hosts on same CPU, OS and so on...

aciddose, thanks for looking into this!

It works fine in my other host (REAPER) on the same machine so I guess it must be related to the version of Orion I am using (version 8.506).

When I open the plugin it shows an empty interface but the Orion toolbar is normally available, I can browse the presets and also hear the sound when playing the keyboard.

Strange things happen though when I try to collapse the window (double click) or when I enter the "edit pattern" mode and then exit it - the toolbar is no more available and whole window shrinks to just few pixels.

Attaching some screen shots.

[aciddose]

If the window itself is modified this is 100% a problem with Orion and not something I can fix. Xhip never has access to the window containing the GUI, it only creates a window inside that larger "frame" called the "client".

https://en.wikipedia.org/wiki/Window_decoration

The fact Xhip doesn't show up at all tells me there is something very wrong with the code that asks Xhip to create its client. If you do not get a message box however, the code itself functions correctly.

The current versions work perfectly in the demo I have, including all additional features such as transparency, resize and so on.

It is likely Orion suffered a regression (a change which caused previously working code to fail) or introduction of new bugs at some point before the version you're using.

Do you have any earlier versions you can use to test? Are there features introduced in the version you're using which you can't live without?

One thing we can do to test this is I can create the client window outside the parent window passed by the host. This should display the GUI, but it will pop up free from the "frame" controlled by Orion.

http://xhip.net/temp/xhip_alpha_ext_window.zip

Does the GUI show correctly in this? The actual GUI should appear in the top-left corner of your display in a normal window frame, although the minimize/maximize/close buttons won't do anything.

I'm also able to get it to create the tiny 1 pixel wide window when I double click then expand the window again. I'll try to look into this but I suspect Orion handles these actions completely on its own without informing Xhip. In other words editor::close or editor::open, editor::getsize are never called. I'll verify if that's the case soon.

Oh! If I double click on the single pixel wide window, it goes back to normal width with the client area gone. It seems Orion is doing some particularly naughty things by making assumptions about how the client window is set up.

If it were to try to read the client rect using Windows rather than VST functions, in the case the client rect is empty it would get rect(0, 0) returned. It seems based upon this it creates the 1-pixel wide and (I guess height of decoration?) unknown value tall window.

With the demo version I have however, testing the normal plugin and doing this works perfectly.

http://xhip.net/temp/xhip_alpha_normal_window.zip