Xhip vs Analog Hardware

[IncarnateX]

Why the hell should I support you? Have you paid me? Or am I expected to just offer my condolences due to being such a wonderful guy?

Got a point there!

But so does he:

I'm sorry, it is probably my fault. But after you wrote in so many threads how much coding experience you have and how bad all the stuff is others do, I really expected more

Say no more, say no more

[aciddose]

No, please do say more. I'd like to see a quote that would have anything to do with this.

Xhip doesn't include oversampling internally because it isn't required in a majority of cases.

In some cases it is and you should be using an external tool or simply increasing the host sample rate.

For the vast majority of users none of this stuff is an issue. The easiest solution in this case is to use the 12db mode.

https://soundcloud.com/xhip/hah
http://xhip.net/alpha/releases/presets/hah.zip

That said, the 24db mode works fine for me.

The issue you have is that you're comparing Xhip to another synthesizer and expecting to get the same results. This doesn't make sense. Xhip is unique. If you don't like it, don't use it!

I prefer it by far.



The same effect occurs at any rate but once nyquist is greater than 26k it won't influence the peak amplitude of the filter oscillation as much.

The "issue" (if you'd call it that) can be solved by adding more processing. It just isn't worth it since doubling the processing cost is the same as running at 96k sample rate. You might as well just oversample. (Technical note: the issue is the coefficient approximation.)

The real issue is the fact this is a pair of 12db filters in series. If I were to add a true four pole filter (global feedback around all four poles) it would behave the way you expect at any sample rate.

[Mutant]

@ 2:15
My attempt with 2 Xhips, Tal Chorus XL, ReaEQ, epicVerb:
https://app.box.com/s/s5pd04z4iwpor6by5pjugm8nusc0norb
First half original OB6 sound, then short fade and second half made by me.
Not perfectly matched but close enough for me.

[stillshaded]

any skins you can recommend for this synth?

it's kind of small on my monitor

[Mutant]

any skins you can recommend for this synth?

it's kind of small on my monitor

Left click on the logo to change color, right click on the logo to change size.
I like the smallest size and different colors for different sounds, my screen looks like a rainbow !

[aciddose]

There is no skinning support.

[stillshaded]

any skins you can recommend for this synth?

it's kind of small on my monitor

Left click on the logo to change color, right click on the logo to change size.
I like the smallest size and different colors for different sounds, my screen looks like a rainbow !

Hmm.. Not working for me.. Maybe I need a newer version?

[Mutant]

Probably. But keep the old version just in case.

[aciddose]

The resize is an alpha feature which isn't 100% tested yet. It isn't expected to work correctly, be finished or so on.

I'm only using a ~120 dpi monitor, so the GUI feels fine at its native size for me. I also really dislike the blur added by rescaling.

I do use it though. You can get the alpha version on the Xhip page although please read the info on the page if you do so. Essentially, I can't and won't (would be a waste of time) vouch for the alpha version to actually, well... work.

I don't have the original sources for the background bitmap and when I rebuild it, I will need to do so from scratch. Most likely I'd prefer to create a system that can render static backgrounds in code. The background would then be created at a specified size, the text + shadows layer would be added on top and the whole thing stored. This is just a complicated thing to accomplish... It's essentially making Xhip "vector based" while still taking advantage of the optimization/caching of bitmaps, and without any need for hardware acceleration or features beyond a standard blit (bitmap copy) function.

That said I have been playing with the feature quite a bit and I'd like to include it in the next release.

The only thing I can say about "when?" is that the more things I do the longer it takes

The layering feature has pissed me off... I'm having a hard time not focusing on it. Apart from that I have the routing + effects functions. Effects will remain in alpha although the routing feature is part of the next release.

The ability to store wavs/pcm in presets and banks is another thing I'd love to have. I did implement this in the past, years ago... around 2009. Although I've lost the code for that. (Apparently. I remember implementing it. Was it a dream?)

In any case getting it to work efficiently is a bit complicated and there is a lot of extra code involved. For example if you load ten presets with the same sample, should it load ten copies of the sample or identify that these are the same? It isn't "hard" to do so, it just takes time. I think functionality like that is the difference between it remaining an alpha feature (something I'm not proud of) vs. being part of a release.

[Mutant]

If you mean store the actual sound data in the preset file, then i am not sure if it is a good idea.
But if you mean store a path to the .wav file, then yes it would be nice.

[aciddose]

A path isn't really practical. You can't share the presets (they require the file to exist in that path) and so on. So the existing system of manually loading the .wavs file makes sense. Although, it would be nice to have projects do that automatically on load of course.

For presets using smaller samples such as banks configured for a particular set of drum sounds though, it makes a ton of sense to store the samples inside the presets and bank + state. The state is what gets saved in the project of course. (Same as a .fxb, NOT the same as a Xhip bank .adxb which is a bank only, not state info.)

Are you thinking of any problems in particular? Large/oversize samples?

I can't really see Xhip being used for that very often so it doesn't worry me much. Of course there would need to be some kind of system where you'd have to intentionally "save bank AND samples", which is why "replace buttons with menus" is on the todo list.

When saving a project Xhip would need to internally determine whether to store the samples. I might have an option for this (the checks / LEDs in the control panel) "store PCM", where if it isn't checked (it is by default) only the path is stored.

These sort of things are those that get worked out by actually implementing the system and worrying later

[Mutant]

I just think that having the audio data in just 1 place instead of 2 places would be good.
There should be no problem with sharing both presets and samples the presets use, just like in SFZ sample player for example.

[aciddose]

Mostly what I want to do is save the samples or path to them in project files so you don't need to re-load them every time.

That was how I implemented it years ago. Unfortunately I think I remember that I accidentally overwrote my changes with a backup and once I noticed it was already too late. That was in the "xhip 2" project I was working on back then. I still have it but there is no remaining evidence of this feature.

It only took me a day to do back then though so it shouldn't take long now. The simple method I used was to add a "PCM" chunk to the state data (fxb). The files weren't stored as .wav, but in the internal "raw" format which is far more easy to work with. I don't know if I added an option to disable it, but I think I did. Only, that option wasn't to store the path instead but not to store the chunk at all.

I think that is where I'll start and I'll add other parts of it later if it works well.

[Mutant]

It only took me a day to do back then though so it shouldn't take long now. The simple method I used was to add a "PCM" chunk to the state data (fxb).

Would saving all parameters in Route and Effects pages be as simple too ?
If yes, then is it high on your to-do list ?

[aciddose]

None of them are "simple" in terms of I'd just be able to do them by snapping my fingers. We're talking sitting down and working hard at the issue for 8 to 12 hours or more.

Yes, each one individually might be accomplished in that amount of time.

Effects shouldn't be a concern as it won't be included in the next release. As things are now this is a far more major undertaking than the route page.

The route page internally depends upon a formatting of the data, so simply writing out that data into chunks inside the state is relatively simple.

The effects however have no such formatting of the data. The parameters can be simply stored as floats and I'll likely do so. As it is though the effects don't even save chunks in their complete form (as individual plug-ins) and don't support features like presets.

The issue remains however with presets and banks - where to store the data, what data to store and when and where to load which data that has been stored? It is reasonably easy to store everything in the state as this is most important anyway. It should be possible to accomplish within a reasonable amount of time.

The todo list is right here (near bottom): http://xhip.net/alpha/

Xhip isn't even on my "actual work" todo list. I work on Xhip when I feel like taking a break AND I still want to write code or do actual work. A rare occurrence