KVR Audio

djsubject · Post by **djsubject** » Thu Mar 08, 2007 1:26 pm

yippie!!

a xhip update

Subz

aciddose · Post by **aciddose** » Fri Mar 09, 2007 1:15 am

"do you have any plans of porting this baby for Linux? Just curious. It'd be so nice if more people like you ported their work for Linux, too."

http://xhip.cjb.net/xhip/releases/v0/b6 ... 6.11.12.so

i'm still working out how to create a unified build step. i think i'll be moving the windows development to linux using mingw cross compile. this version i think has the gui enabled, which immediately crashes for me. others have reported xhip works fine though. it is apparently dependant upon what libs you're using. ubuntu running gnome with xt2 is the recommended configuration according to those who have gotten it to work.

sinkmusic · Post by **sinkmusic** » Fri Mar 09, 2007 1:45 am

Gsoto, is there anything new about the GUI ?

DuX · Post by **DuX** » Fri Mar 09, 2007 3:37 am

Freaking good Aciddose, nice to hear that!

gsoto · Post by **gsoto** » Mon Mar 12, 2007 3:19 am

sinkmusic wrote:Gsoto, is there anything new about the GUI ?

Not much, really

I'm not sure if it's a good idea to keep posting screens right now because the attention gets into the GUI and I believe there are more urgent things to implement. Mainly the "stable" patch format, in my opinion.

acid, looks like the last changes turned the synth up one semitone.

aciddose · Post by **aciddose** » Mon Mar 12, 2007 7:36 am

yep, i made a mistake in the offset calculation.

http://xhip.cjb.net/xhip/releases/v0/b6 ... .11.16.dll

in this version i've also made modulation depths more accurate (1.0 is 1.0, instead of 0.996) and the filter modulation depth is exponential just like the frequency mod depth.

sinkmusic · Post by **sinkmusic** » Mon Mar 12, 2007 7:38 pm

gsoto wrote:
sinkmusic wrote:Gsoto, is there anything new about the GUI ?

Not much, really

I'm not sure if it's a good idea to keep posting screens right now because the attention gets into the GUI and I believe there are more urgent things to implement.
/quote]

Not really sure about that.
I mean, to my point, there are som many updates and fixes and versions numbers that i get lost rather easily.
And wrapping a GUI on that synth would be a way to put a "milestone" (is it the correct word?), to say : "ok, i'm still working on it, but now this one is a reference, and not only a 'neverending work in progress'..".
And to me, xhip already works rather well, except that when i load a new versin, most of the time it looses the preset bank, and i always have to re-load it.
As it happened on a project and lost the preset reference, i'm not using xhip in a project any more, and it is a pity because the synth sounds good (and changing the synth name's version also contributes to losing refenrece when the host is looking for the plugin).
It is only my 2 cents, and i think i am the only one "complaining" (well, i'm not complaining, the synth is fine, it is free, and i understand & respect the dev's choice), but to my own egoists needs, i know that putting a gui and a "stable" version number on it with embedded presets would help me to get more familiar with it.

aciddose · Post by **aciddose** » Mon Mar 12, 2007 8:32 pm

the gui wont make for a "Stable" version anyway. there never will be a stable version. i can implement gsoto's gui, but it will not work correctly the way things are right now. if a current version of the synth works good for you, use it and stop "upgrading". if you feel you absolutely have to "upgrade", obviously you're not being honest with yourself when you say "xhip already works rather well".

gsoto can not "do" the gui anyway, i still have to write 100% of the code.

gui already has a gui, btw

gsoto's gui will be a secondary/optional gui. the main gui, the official gui, is the existing one. once everything is working and has been tested, (six months after gsoto's gui is working perfectly) i might consider making it the offical gui, it depends on how things go. by that time there will be other guis available as well.

if you check http://xhip.cjb.net/xhip/todo.cgi you'll see when the next "stable" version is. what gsoto said about "more important things" in part requires reference to the todo in order to understand. you'll see "fully implement gsoto gui" is below many other things. those were the "more important things" he talked about.

AdmiralQuality · Post by **AdmiralQuality** » Mon Mar 12, 2007 8:39 pm

aciddose wrote:http://xhip.cjb.net/xhip/releases/v0/b6 ... .11.16.dll

Have you gone backwards in your version numbering AD? Should I replace 0.6.11.6 with this?

EDIT: Oh, never mind, I get it now.

aciddose · Post by **aciddose** » Mon Mar 12, 2007 10:29 pm

i use a versioning system similar to debian packages, where there is: stable.testing.unstable-revision. my versioning is basically the same, but for some reason i called them release.beta.alpha.revision

sinkmusic · Post by **sinkmusic** » Mon Mar 12, 2007 10:45 pm

aciddose wrote:the gui wont make for a "Stable" version anyway. there never will be a stable version. i can implement gsoto's gui, but it will not work correctly the way things are right now. if a current version of the synth works good for you, use it and stop "upgrading". if you feel you absolutely have to "upgrade", obviously you're not being honest with yourself when you say "xhip already works rather well".

gui already has a gui, btw

Yes, you're 'right'.
This is why i took the care to say that it was only my very own point of view on this, and i am aware it is not any kind of truth, just a personal take on it. I just meant i'd be more cumfortable with xhip and the Gsoto GUI (it would make me feel like some point were reached and that i can stand a moment with this one). I also know it is not very rational, because it is not the GUi which makes it good sounding of course, but i know that i use Oatmeal a lot more since Grymjack did his own skin for it

You're also right : i follow the thread, but didn't 'updated' Xhip for months, as the version i have works fine for my needs. But i saw on the forum that many features were added, and, caught by a vstleechermania, thought "hey, let's give this new version a try!", but ended with empty presets

And yes, too, there IS already a GUI

aciddose · Post by **aciddose** » Tue Mar 13, 2007 9:39 am

i didnt mention my reason for using the new frequent updates and versioning numbers. the reason i'm doing that is you should be able to more easilly find if there is a bug introduced, exactly where it was introduced due to the smaller changes between versions.

if you want a particular version in a track, since updates are so small you shouldnt have to suffer with a new release that has 100 updates that you can not use.

with the increasing number of available archived releases, selecting the one you want is indeed difficult if you do not have any clue how to do so. to fix that i'll be including a summary for every release on the releases page. it'll put the .info content directly into the page so you do not need to seperately access those files. i'll also make the default releases page a "latest release" page which displays only the latest versions in each of the four sections and a summary for each, with a link to a detailed list of changes for each as well.

i need to change my .info format so that i can connect changes/comments togeather into .info files for groups of releases.

most people will want to simply continue to use the next versions while keeping the old files in their vst directory. if you keep all the files there hosts will be able to use the old versions for old projects and you will not have this upgrading issue. that is another main reason i started versioning the filenames. for new projects, use the latest version. for old projects, continue to use the old version you started the project with.

AdmiralQuality · Post by **AdmiralQuality** » Tue Mar 13, 2007 10:30 am

Just curious, does that mean you change the VSTID for each version AD? If not, certain hosts won't load the duplicates (Bidule is one but I think there's others) and there's no way to specify which of the different versions to use based purely on filename. (I'd say this is the host's fault, as the Steinberg hosts have no problem with this... they seem to combine the VSTID with the .dll name to further disambiguate which plugin .dlls are loaded in your project.)

But part of our job is programming for the lowest common denominator host features, so I thought I'd point this out.

If you do use separate IDs for each release, do you register them all with Steinberg?

aciddose · Post by **aciddose** » Tue Mar 13, 2007 10:48 am

no, it isnt practical to use seperate ids. i consider the dword id of vst plugins to be useless, and i ignore it. it is a major flaw in the vst specification.

modern vst hosts should create a 256 byte or greater length identifier based upon a combination of all available information from the plugin, including name, vendor, version, product string, filename, in/out channels, and other options set by the plugin. it doesnt make sense for a host to load a five channel plugin in place of a stereo plugin, and there are many other cases with the other options which are similar. seperate bits of identifying information can be used with differing importance so that in the case for example the same plugin name is available yet only in a different version, the user can be asked if the differing version should be loaded in it's place.

i'm not aware of the internals of properitary hosts of course, but i have no heard any complaints from users.

AdmiralQuality · Post by **AdmiralQuality** » Tue Mar 13, 2007 10:52 am

Ah. Life in the vacuum is so much simpler. Don't like the spec? Declare your own rules!

How do you ignore it anyway? It's got to be something. Are you saying you don't call setUniqueID()?

You're potentially conflicting with some other developer's products. You say people don't complain? My guess would be that's because they know they get what they pay for and don't have much right to complain.

XHip--Please finish your synth!!