http://xhip.cjb.net/xhip/releases/v0/b6 ... 6.12.9.dll
changed the patch internals over to float in preparation for the first steps of upgrading the patch format.
these are removed from the todo:
- update synth voice architecture to allow float format control data (ie. ability to deal with cutoff range from -inf to +inf rather than 0 to 1)
- change format for voice data from char to float - stupid, but more flexible
is this working ok?
XHip--Please finish your synth!!
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
Grrrrrrrr. Changing the notelogic slider crashed SX3 and took out the ASIO driver. (I may have been playing while sliding it.) Now I need to reboot. Grrrrrrrrr.
I was making you a patch that I was going to suggest you use as the new default too! That may have been saved, we'll see...
Did I say "Grrrrrrr" yet?
I was making you a patch that I was going to suggest you use as the new default too! That may have been saved, we'll see...
Did I say "Grrrrrrr" yet?
-
- KVRian
- 673 posts since 15 Nov, 2004 from Montevideo, Uruguay
Yay for the changes.
And Grrrrr + 1; same problem as AdmiralQuality here.
Saving and loading doesn't seem to be working too.
Current list of problems/bugs:
- band stop and peak mode act weird
- waveshaper messed up
- crash with notelogic and unison sliders (load Xhip, hit one note, and move any of the sliders)
- saving/loading problems
And Grrrrr + 1; same problem as AdmiralQuality here.
Saving and loading doesn't seem to be working too.
Current list of problems/bugs:
- band stop and peak mode act weird
- waveshaper messed up
- crash with notelogic and unison sliders (load Xhip, hit one note, and move any of the sliders)
- saving/loading problems
-
- KVRAF
- 12615 posts since 7 Dec, 2004
it was started in 1998.
yes, probably
i think you guys need to consider the last 'stable' version, the last stable version. you wont be seeing another stable release for quite some time, i do not care about the current crashing issue because it will require hours (days probably) of debugging to fix. the changes i'm about to make will almost certainly introduce more serious bugs. i'll make all the changes first, then worry about stability later. for the next series of revision/alpha releases you need to expect them to be unstable, and i can actually guarantee they will be unstable.
it will be much less work for me to fix the crashing issues in one swoop after i've made all the changes to the patch formats and stabilized all the implementation.
i'm not sure if you noticed, but you've all been running alpha revisions for the last year
it's really REALLY weird that they've been so stable until now. you are about to see what the normal state of alpha revisions is.
yes, probably
i think you guys need to consider the last 'stable' version, the last stable version. you wont be seeing another stable release for quite some time, i do not care about the current crashing issue because it will require hours (days probably) of debugging to fix. the changes i'm about to make will almost certainly introduce more serious bugs. i'll make all the changes first, then worry about stability later. for the next series of revision/alpha releases you need to expect them to be unstable, and i can actually guarantee they will be unstable.
it will be much less work for me to fix the crashing issues in one swoop after i've made all the changes to the patch formats and stabilized all the implementation.
i'm not sure if you noticed, but you've all been running alpha revisions for the last year
it's really REALLY weird that they've been so stable until now. you are about to see what the normal state of alpha revisions is.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
How the hell does one control LFO depth with the mod wheel on this thing?
Jeebuz, I've been programming analog synths since 1983 but I can't for the life of me figure that absolutely typical function out.
Also, why are the routings done from source to a single target? Rather than each of the targets being able to pick a source? Like the "velocity route" for example? I get to use velocity for only one thing? Choose wisely...
And... do the LFOs not sync to *each other* by default, or is their phase uncontrollable unless synced to the note-ons?
And... woah... I remembered this synth as relatively CPU efficient but it's using as much CPU as Poly-Ana now, which even I admit is a heavy process compared to most other products (JP-8V excepted which IMHO wins the all time piggy prize.)
"Load program" button doesn't seem to work for your .adxi format (or perhaps it's the save? Hard to say.) Using the host to save .fxp does seem to. So here's my suggestion for a "default" patch. (And if there's a way to modulate LFO depth to the oscs from the modwheel, add that too!)
http://www.admiralquality.com/4ad/XHipBrass02.fxp
Oops, just tried loading that .fxp again and Xhip has gone silent, on all programs. Reloading the project now... and the host is hung again! Great.
There's a lesson here folks: "You get what you pay for". Poly-Ana was 1.5 years (full/over/time) in development. 1 year exactly to Beta (which worked pretty good, just was lacking a few of the less frequently used features that make it a truely mature product). But I didn't allow (known) mistakes at any point, so I never hit this stage of it being unmaintainable that we see here. You make things perfect as you go, and don't add more until you're confident it works. Just some advice AD, I'd like to see this working myself (though now that it's a CPU hog too a lot of it's former value is lost to me.)
(Nudge nudge!
)
Rebooting... testing this version is NOT fun...
Jeebuz, I've been programming analog synths since 1983 but I can't for the life of me figure that absolutely typical function out.
Also, why are the routings done from source to a single target? Rather than each of the targets being able to pick a source? Like the "velocity route" for example? I get to use velocity for only one thing? Choose wisely...
And... do the LFOs not sync to *each other* by default, or is their phase uncontrollable unless synced to the note-ons?
And... woah... I remembered this synth as relatively CPU efficient but it's using as much CPU as Poly-Ana now, which even I admit is a heavy process compared to most other products (JP-8V excepted which IMHO wins the all time piggy prize.)
"Load program" button doesn't seem to work for your .adxi format (or perhaps it's the save? Hard to say.) Using the host to save .fxp does seem to. So here's my suggestion for a "default" patch. (And if there's a way to modulate LFO depth to the oscs from the modwheel, add that too!)
http://www.admiralquality.com/4ad/XHipBrass02.fxp
Oops, just tried loading that .fxp again and Xhip has gone silent, on all programs. Reloading the project now... and the host is hung again! Great.
There's a lesson here folks: "You get what you pay for". Poly-Ana was 1.5 years (full/over/time) in development. 1 year exactly to Beta (which worked pretty good, just was lacking a few of the less frequently used features that make it a truely mature product). But I didn't allow (known) mistakes at any point, so I never hit this stage of it being unmaintainable that we see here. You make things perfect as you go, and don't add more until you're confident it works. Just some advice AD, I'd like to see this working myself (though now that it's a CPU hog too a lot of it's former value is lost to me.)
(Nudge nudge!
)Rebooting... testing this version is NOT fun...
-
- KVRAF
- 12615 posts since 7 Dec, 2004
rofl you're using the wrong versions. dont use alpha revisions if you expect stability or proper function. the reason you route from an event to a parameter is because that allows full modularity while the opposite imposes strict limitations. reading your comments, you probably need to try it again next year at this time.
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
Poly-Ana was effectively as "alpha" as this is when it was "Beta". As you know, I did the GUI first (that's how I knew what I was going to build!) The sound code, while based on Naive LPF and SCAMP in the filters, was 100% new, and was for sale in Beta about 4 months after STARTING it. (Arguably Naive and SCAMP were stepping stones on the same project though, so I tend to call it a year to Beta. It was for sale, working well, exactly year after publishing my first VST plug-in.)
It's just a work ethic thing dude, and I'm just trying to nudge you in the right direction. I do understand that we have no right to complain about something that's free. But I'd like to see you make something of this because it sounds not bad. It's just losing me on certain architectural decisions and your lack of "follow through".
(So how do I make the mod wheel work anyway?)
It's just a work ethic thing dude, and I'm just trying to nudge you in the right direction. I do understand that we have no right to complain about something that's free. But I'd like to see you make something of this because it sounds not bad. It's just losing me on certain architectural decisions and your lack of "follow through".
(So how do I make the mod wheel work anyway?)
-
- KVRAF
- 12615 posts since 7 Dec, 2004
i think what you miss out on here are two things:
1) i do this in my free time. if you do not understand just from implication all the things which i could go on to describe based upon this, i'd be wasting my time anyway.
2) i write xhip for myself. if i want it to do something, i work and i make it do whatever i want it to do. i'm not here to please anybody or for any other purpose. i take the time to try to work with others for two purposes, first because i want to share what i've produced with them, based upon my assumption that they might want some of the same things. second because when they want something i do not want, at times i can discover new things that i will enjoy and i may not have had the chance to enjoy without having been shown these things be someone else. this is give and take, i write the software, others help me out with ideas.
there is nothing that could possibly motivate me to enjoy myself.. that doesnt make sense. what can motivate you toward enjoyment any more than the enjoyment itself? like i said you should really take another look in a year from now, when it'll be either at or beyond "v 1.0" as people call it. it should satisfy the things you've asked for and more at that point. until then.. well, these things take time. i assure you that if i were capable of pulling the finished product from my ass immediately without any effort, i would definitely do so.
1) i do this in my free time. if you do not understand just from implication all the things which i could go on to describe based upon this, i'd be wasting my time anyway.
2) i write xhip for myself. if i want it to do something, i work and i make it do whatever i want it to do. i'm not here to please anybody or for any other purpose. i take the time to try to work with others for two purposes, first because i want to share what i've produced with them, based upon my assumption that they might want some of the same things. second because when they want something i do not want, at times i can discover new things that i will enjoy and i may not have had the chance to enjoy without having been shown these things be someone else. this is give and take, i write the software, others help me out with ideas.
there is nothing that could possibly motivate me to enjoy myself.. that doesnt make sense. what can motivate you toward enjoyment any more than the enjoyment itself? like i said you should really take another look in a year from now, when it'll be either at or beyond "v 1.0" as people call it. it should satisfy the things you've asked for and more at that point. until then.. well, these things take time. i assure you that if i were capable of pulling the finished product from my ass immediately without any effort, i would definitely do so.
-
- KVRAF
- 2910 posts since 26 Jul, 2005 from dun unda
Thought it would've been beta... Anywho..aciddose wrote:i'm not sure if you noticed, but you've all been running alpha revisions for the last year
it's really REALLY weird that they've been so stable until now. you are about to see what the normal state of alpha revisions is.
Yeah, it is a miracle, though considering the time you initiated this project, I'm rather awed. since 1998?!?!?! Holy shit
That's 9 years in the making!
-
- KVRAF
- 12615 posts since 7 Dec, 2004
ahw! my spleen!
but actually i'll answer to aq's concerns. with these things you're still just misunderstanding the way things work here. i've been always asking people, please do not invest too much time into xhip until it is finished. please do not depend upon xhip, or depend upon it being finished (or certain issues resolved) within a fixed period of time. things might change in my life and i can tell you xhip will be on the bottom of the list of important things, after many things like for example: feeding myself, having a place to live, those things.
it isnt that "it's all about me and anybody else can suck it".. it's more like, i try to work on xhip as much as i can because i know not only do i use it, but others use it as well. when people have legitimate concerns about something, i usually try to listen to them and address those concerns. people make suggestions, they ask for features, i implement a lot of the stuff people ask for.
my over-all plan for xhip was finished a long time ago.
in 1998 i began creating what would be called an "offline synth" for rendering short samples to use in a tracker. in 1999-2000 i started to create my own trackers (about three of them) and i turned the un-named synth at the time into a off-line synth capable of rendering whole tracker sequences. after that, i started to work on a real-time tracker sequencer with the synth built in.
around 2003 i was getting bored with that and a number of people in #modarchive started to ask me if i considered writing a vst version. i had always disliked the vst format, but i was finally convinced to do it. in 2004 the vst version was working fairly well, i had written a stand-alone version, i had updated my tracker to one of considerable power (for something started in 2000.. by 2004 it was becoming obsolete) and somebody suggested i post news of these in several scene message boards.
in december of that year some people had been suggesting that i take a look at kvr in order to post news about the vst version since kvr was supposed to be "the vst scene news site". i did, somebody started some threads and joined the message board here.
since that time i've been concentrating a lot of my efforts here. the tracker and stand-alone were dropped in favor of a vst host, vst mini-host and vst plugins. i translated the effects i wrote for my old trackers into basic vst plugins. all this time i've been writing this software because i both enjoy writing software period, and because i've been unsatisfied with the software available to do what i want to do with music.
so, my original plans for xhip were to simply convert it to a vst and post it on kvr. that would be probably, this version here http://xhip.cjb.net/xhip/releases/v0/old_xhip_vst.dll
when i started adding a gui with vstgui.. that was outside the scope of my original plans. since then i've thrown out vstgui and written my own gui libraries. i've thrown out gdi and written my own graphics systems. i've written my own 3d renderer and engines. i've written complex object oriented systems to replace the old c style systems i wrote about 6 years ago. a lot of stuff i never planned to do. if i had ever planned on writing xhip exactly the way it is now, it wouldnt have taken me so long.
the first stable release (1.0.0.0) will just be the first version where i really feel xhip is a package that can be used by everybody without any complaints. if you do not understand how many things are involved that need to be delt with to get to a point like that then, i cant possibly explain it to you. there is a lot of work left to do, yet there has been a lot of work already done as well. the source for xhip is about 500kb, i'm not sure how many "lines" (irrelevant anyway) and made up of 80 source files.
if you'd like to see exactly what needs to be done before the next beta release, and you should have your requests satisfied by that point, look here http://xhip.cjb.net/xhip/todo/ http://xhip.cjb.net/xhip/faq/
if your requests are not satisfied by that version once i release it, you will have a chance to talk with me before i write the todo list for 1.0.0.0.
but actually i'll answer to aq's concerns. with these things you're still just misunderstanding the way things work here. i've been always asking people, please do not invest too much time into xhip until it is finished. please do not depend upon xhip, or depend upon it being finished (or certain issues resolved) within a fixed period of time. things might change in my life and i can tell you xhip will be on the bottom of the list of important things, after many things like for example: feeding myself, having a place to live, those things.
it isnt that "it's all about me and anybody else can suck it".. it's more like, i try to work on xhip as much as i can because i know not only do i use it, but others use it as well. when people have legitimate concerns about something, i usually try to listen to them and address those concerns. people make suggestions, they ask for features, i implement a lot of the stuff people ask for.
my over-all plan for xhip was finished a long time ago.
in 1998 i began creating what would be called an "offline synth" for rendering short samples to use in a tracker. in 1999-2000 i started to create my own trackers (about three of them) and i turned the un-named synth at the time into a off-line synth capable of rendering whole tracker sequences. after that, i started to work on a real-time tracker sequencer with the synth built in.
around 2003 i was getting bored with that and a number of people in #modarchive started to ask me if i considered writing a vst version. i had always disliked the vst format, but i was finally convinced to do it. in 2004 the vst version was working fairly well, i had written a stand-alone version, i had updated my tracker to one of considerable power (for something started in 2000.. by 2004 it was becoming obsolete) and somebody suggested i post news of these in several scene message boards.
in december of that year some people had been suggesting that i take a look at kvr in order to post news about the vst version since kvr was supposed to be "the vst scene news site". i did, somebody started some threads and joined the message board here.
since that time i've been concentrating a lot of my efforts here. the tracker and stand-alone were dropped in favor of a vst host, vst mini-host and vst plugins. i translated the effects i wrote for my old trackers into basic vst plugins. all this time i've been writing this software because i both enjoy writing software period, and because i've been unsatisfied with the software available to do what i want to do with music.
so, my original plans for xhip were to simply convert it to a vst and post it on kvr. that would be probably, this version here http://xhip.cjb.net/xhip/releases/v0/old_xhip_vst.dll
when i started adding a gui with vstgui.. that was outside the scope of my original plans. since then i've thrown out vstgui and written my own gui libraries. i've thrown out gdi and written my own graphics systems. i've written my own 3d renderer and engines. i've written complex object oriented systems to replace the old c style systems i wrote about 6 years ago. a lot of stuff i never planned to do. if i had ever planned on writing xhip exactly the way it is now, it wouldnt have taken me so long.
the first stable release (1.0.0.0) will just be the first version where i really feel xhip is a package that can be used by everybody without any complaints. if you do not understand how many things are involved that need to be delt with to get to a point like that then, i cant possibly explain it to you. there is a lot of work left to do, yet there has been a lot of work already done as well. the source for xhip is about 500kb, i'm not sure how many "lines" (irrelevant anyway) and made up of 80 source files.
if you'd like to see exactly what needs to be done before the next beta release, and you should have your requests satisfied by that point, look here http://xhip.cjb.net/xhip/todo/ http://xhip.cjb.net/xhip/faq/
if your requests are not satisfied by that version once i release it, you will have a chance to talk with me before i write the todo list for 1.0.0.0.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
regarding the speed of the code at this point, i've removed all conditional statements so that every patch requires a nearly equal amount of cpu. playing a simple square in xhip is now equal to having everything enabled. i'll optimize the unneeded sections of code away using smc in the future, as shown on the todo list.
once i've done that xhip will be considerably faster than it has ever been. if anybody has an issue with the moderately increased cpu requirements for small patches (for full patches, it is actually decreased) i can add the conditionals back at any time with very little effort.
the current issues are shown on the todo list. those need to be completed so i can actually move ahead with xhip. if i spend time fixing the current bugs, that will leave me in the same place on the todo list and it is likely after i implement the code on the todo, more bugs will be introduced anyway.
once i've done that xhip will be considerably faster than it has ever been. if anybody has an issue with the moderately increased cpu requirements for small patches (for full patches, it is actually decreased) i can add the conditionals back at any time with very little effort.
the current issues are shown on the todo list. those need to be completed so i can actually move ahead with xhip. if i spend time fixing the current bugs, that will leave me in the same place on the todo list and it is likely after i implement the code on the todo, more bugs will be introduced anyway.
-
- KVRian
- 533 posts since 16 Jan, 2006 from France
Well the problem is I have a lot of patches that won't load with newer versions... but I know... as you said "do not depend upon Xhip"aciddose wrote:Once i've done that xhip will be considerably faster than it has ever been. if anybody has an issue with the moderately increased cpu requirements for small patches (for full patches, it is actually decreased) i can add the conditionals back at any time with very little effort.
hehe... So I guess I'll stick to that old version I have on which I made quite a complex patch which I feel real lazy to try to reproduce by hand.To be honest, I'm with AQ on this, I've always found your criticism about modulation matrix very strange. You may be right saying it's obsolete and lame but when you say :AdmiralQuality wrote:Also, why are the routings done from source to a single target? Rather than each of the targets being able to pick a source? Like the "velocity route" for example? I get to use velocity for only one thing? Choose wisely...
You may be perfectly right there even if it's still unclear to me what's the concept behind this "event routing" I see listed in the TODO section and to what extent it's actually better than good ol' mod matrix... In the meantime -and we alread talked about this- Xhip is very crippled in the modulation department (since it only accepts a single source of modulation), and that string patch I was working on can't be enhanced further due to this limitation...aciddose wrote: the reason you route from an event to a parameter is because that allows full modularity while the opposite imposes strict limitations.
Again I'm not really complaining, I know you do it for yourself, but the fact is that it's a very good sounding synth (which should be much more famous imo) and it's frustrating not to be able to actually produce and share patches from this beauty.