Xhip vs Analog Hardware

[aciddose]

You're using a sample rate which is too low. Try at 96k.

The filter has a minimum oscillation point to ensure stability. This is required unless the filter is made far more expensive (about 3x.)

The 12db filter doesn't have this issue. This is due to the fact the 24db mode is actually two 12db filters in series.

Xhip works okay at 48k, it does not work below that rate. People insist on using 44.1k but unfortunately there are numerous reasons this is a bad idea.

In any case this isn't an issue. It is intentional.

[aciddose]

Regarding the fact the filter doesn't "self oscillate", this is also intentional.

Use the filter "trigger" mode set to "impulse" to set the filter to oscillate immediately.

Alternatively, ensure the filter is oscillating before you do your sweep.

The reason is that the maximum feedback amplitude in Xhip is 100%. Analog filters allow 110%, 120% which is why they "burst" into self-oscillation. Xhip is not VA.

[aciddose]

Regarding making radical changes to a 10 year old synthesizer: No.

Sure, I might like to if Xhip was new, but it isn't. I hardly invest enough time to the areas which actually need work, making senseless changes to the synthesizer would be a waste of effort.

I already spend that time on other, new synthesizers which is why Xhip doesn't get much attention anymore.

Xhip needs a manual to explain functions. People might find the PW modulation counter-intuitive if they're accustomed to software. In reality however the exact same "issue" exists on every synthesizer such as the JUNO synths or similar. If you use the ramp/saw waveform, pulse-width doesn't take effect.

Although, in Xhip it is re-used for ramp (unison detune) and triangle (tri->sine) although in the alpha there is a separate sine waveform.

PW is also re-used for PCM, where it is waveform start offset.

Has no effect on S&H noise.

[aciddose]

- loading (different) wav files always results in "error in riff, fmt chunk"

Link one of these files here and I'll tell you what the error is. Most likely your files are not in PCM format.

Format = 1 (pcm) is required. Xhip can't decode 64-bit, floating point (32-bit), 24-bit or other formats.

Xhip can decode multi-channel formats so long as the data is PCM 8-bit or 16-bit, however it simply uses the first channel and discards the others.

I should improve the error messages at some point but this isn't exactly high on the list.

[aciddose]

Regarding what I'm actually focusing on:

edit: removed old image links

I'm working on this tool to display cycle counts. It "works" although it needs some significant improvement to be useful. (the window name = rdtsc is from eight years ago. the tool doesn't even use rdtsc instructions anymore!)

Last night I managed to get the overhead low enough that the cycle counts it actually displays are accurate for elements without children. So, "process" includes the overhead of computing the cycle counts for the child elements which throws the number off. For each element inside "render" however the ratios between measured elements are accurate with zero overhead. This means for example where you see the filter takes 10,000 cycles and 30,000 for each oscillator, it means the ratio is 6:1 for oscillators.

Now the issue - these particular numbers are with optimization disabled as I'm in the middle of working on the tool rather than using it. Still though although this might improve with optimization (maybe 2:1 or 3:1) it is clear the oscillators are incredibly inefficient compared to the filters in Xhip.

...and why am I working on this tool? It is because I need to work with / optimize the oscillator code So my guess was at least roughly accurate.

Yes with optimization it's 3:1. This is also using 16x oscillator unison of course, which emphasizes the overhead of certain components of the oscillator as they are multiplied near 16 times. With straight oscillators it's 1.3:1, although this is using the 2-stage filter modes. With single stage (12db) it's 1.5:1, or each oscillator is 4:5 the cost of the filter.

The oscillators should be far less expensive more like 2:5 or less. Since the ratio is so high, optimizing the oscillators could have a significant impact.

The filters can't be optimized Unless I used some crazy method like computing four voices at once. Xhip can't do this because there isn't a single "master preset" shared by all voices. Each voice is an individual isolated from the others and so they can't be computed together.

edit: removed old image links

Slight improvement. (The other screenshot wasn't dividing the counts by the number of samples taken.)

These numbers also aren't in "cycles", I was using that term because the code used to use RDTSC, and "in theory" (to my knowledge) it might have been possible to convert between "ticks" and "cycles" in the past. Now though with multiple cores and all sorts of other issues measuring in CPU cycles isn't simple. So anywhere I say "cycles", replace it with "ticks" or "T".

[aciddose]

Regarding different types of noise, it may be possible to provide pink/brown noise as a switch in the mixer but beyond this it requires adding parameters.

If any parameters are added or significant modifications made to the synth, it'll be for version 9, not 8. 8 is already taking way, way too long.

[.jon]

I'm using 48KHz, which is a dramatic improvement from 44.1... but maybe I just don't have the ears or gear to notice as big improvement when going higher. Maybe it's just the plugins I'm using and 44.1, don't know and the reasons < results in this case. And my old m-audio crapterface doesn't seem to like 88.2, so 48 is it.

Interesting to see how (relatively) expensive modulation is, guess it makes sense when I think about it, never really considered what an envelope for example actually does in the DSP domain.

New projects sounds interesting, there's a lot of VSTis out and there and not that many with an actual character.

Btw triangle wave is named "Ramp" in the LFOs, and parameter value display isn't updated when using MIDI to tweak them.

[aciddose]

Both intentional.

The modulator doesn't have a "triangle" it has "ramp" which is controlled by width from up-ramp to up/down (often referred to as triangle) to down-ramp. Same with the fact it doesn't have "square", it uses "pulse" which can be adjusted by width.

The oscillator waveform is called "ramp" because this is the proper term for the waveform. In electronics the only time "saw" is used is when you are describing a ramp with a skew to it (as in when high-pass filtered) which is the same as the shape generated by a RC relaxation oscillator. Synthesizers use integrators and not RC filters in their relaxation oscillators and so using the term "saw" has never made sense. The waveform you get at the output could be referred to as "saw", although the waveform generated by the oscillator can not.

The term "LFO" doesn't make sense as the modulators are not limited to low-frequency.

There is no reason to display anything on the GUI in response to automation. It would be extremely wasteful. Control via the CC "learn" function ("map CC") is the same as automation input. In fact it simply calls VST's automation "set parameter" function.

Of course it might make sense if you're using a controller with knobs and looking at the screen, yet the GUI might not even be open. The knobs are updated to reflect the value but text isn't printed on the display. The reason for this is simple, it is that the update needs to occur immediately and the text lookup/render (the actual text, not the graphical operations) is not very fast.

The only time I know the input is on the GUI and the user is definitely looking at the GUI is when the input is from the mouse.

Another issue is that usually there is only a single cursor/pointer with a mouse, while automation can apply to every parameter at once. This would lead to flickering/conflicts between parameters as the screen (the text display's text content) is updated thousands of times per second.

Due to the fact that a lot of users leave the GUI open while handling automation tasks and the cost of applying these updates (especially in consideration of the cost vs. benefit) it doesn't seem a worthwhile feature to include. In fact it would be detrimental in my opinion.

The host can request this text from the plug-in, and there are controllers out there that can display such text. If it were really of much benefit this would be a much more rational approach to take (looking at the controller) rather than staring at the screen.

That said, I'm not aware of much support for such things. The host would need to directly support some protocol for communication with the controller outside the scope of VST or MIDI (as far as I'm aware). Although it is possible to "probe" other plug-ins (peers) with the VST specification I do not believe it is reliable.

I'd be willing to bet you could achieve something similar to this using OSC controllers in combination with a host like REAPER with some number of customizations. The whole thing might be ready-made by someone out there in fact. As far as the mainstream audio plug-ins world though this sort of stuff is quite esoteric.

[.jon]

Cool, the text update was just something I noticed when checking the reported filter issue, there's no values I'd need to check while controlling it via MIDI. Like you mentioned, I use the hardware so I wouldn't have to look at screen, and furthermore numerical values of many synth parameters aren't particularly useful. However, this can also lead to a situation where the display readout is wrong/out of sync with the actual value.

REAPER can display the value btw when you switch off the plugin UI.

Oscillator triangle is then a triangle?

LFO was just shorter to type than modulator, it is an oxymoron for all LFOs that go to audio rate but the term has stuck well.

[aciddose]

Yes, the oscillator triangle doesn't respond to width adjustment.

It "could", I just never liked the effect and adding it now wouldn't be backward compatible.

In the future it's an option (xhip 2) along with lots of other waveforms.

This is actually what I'm working on. This is why the profiling tool is important, so I can ensure the new stuff I'm working on is equal or better than the old stuff.

No point replacing the basic oscillator in Xhip with a more advanced one if the advanced features make the simple waveforms less efficient.

Regarding display of text on the GUI in response to automation; this is actually possible. It would just take a slightly different design and a bit of rework/refactoring. The reason it is efficient to update the knobs/switches is because they have a value stored. When the value changes, it is updated and the control is marked as "dirty".

The display does store the text, but it doesn't store "display the text for parameter X". So there is significant overhead involved in accessing the parameter and setting the text stored by the display.

In order to work more efficiently I'd need to create an additional layer that plugs into the display and has a "display parameter X" value associated with it. This could then work like any other control and only be actually rendered in text and on screen during a screen update cycle. The overhead would then be reduced to setting the index of the displayed parameter as well as marking the display as dirty.

While that is interesting and all... it just doesn't provide much benefit (if any) as I consider the display to be useful only when using the mouse. If I'm tweaking a parameter from a controller I pay far more attention to the sound I'm getting rather than worrying about the parameter in any way at all.

The actual value is only useful when I'm fine-tuning something, which is always accomplished by switching to the mouse for much more detailed fine-tuning. Even with a knob, you can't get the same precision as the mouse+keyboard provides without a multi-turn knob or rotary encoder. Usually the values I'm sending via MIDI CC are 7-bit. Xhip doesn't even support 14-bit data

[Soundplex]

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... But that Xhip only works in 48kHz and higher is probably the most dumbest thing a developer said to me. Especially when there are methods like internal oversampling to achieve a sample rate the synth will work with, without teaching the customer how bad 44.1 is. So you really like to get rid of all the customers working with 44.1? Thats better than making Xhip work flawless for them?

Btw I can reproduce the Q bug with any sample-rate and any filter type, just the way I described Changing the filter trigger to "spike" makes it even worse, "reset" does the same buggy behavior. It's sad you didn't even try to investigate if it is a bug. You didn't ask me which sample rate I used or whatever, too. Just writing excuses - good support!

The wav reading bug was definitely my fault. I used a normal 24bit file. Didn't know Xhip was that limited with handling files.
But theres the next problem - I don't know what the width is supposed to do on a custom sample. It just takes away the beginning of the sample!?

I totally agree Xhip needs a manual. And I may will test this plugin again another time But for now I'll rather make a soundset for another synth.

Cheers

[Daags]

inb4 customer V user rebuttal.

[Mutant]

Good thing i have the power to lock the thread.

Free synth, no such thing as a customer here.
AD works on it when he has free time and feels like it, i am perfectly OK with that.
Xhip can do things other free (or even payware) synths can't and it sounds great, that's why i use it, that's why i am prepared to work around some of its limitations.

BTW i made my own sweep @ 48Khz, i'll upload it in few minutes.
No problems with the resonance loudness.
https://app.box.com/s/gx7gaasryqzjoqvrkm9inhtyd4d6tn1c

[aciddose]

Xhip doesn't actually have a 24db filter.

If you use the 24db mode, you need to recognize the fact it is two 12db filters in series.

It sounds unique and interesting much like the same filter (implemented with the same method) in the aJUNO.

They're adjusted differently (the aJUNO uses closer to equal parts Q, Xhip uses ~sqrt(2)Q second stage)
and the "not flat" amplitude is shared between them.

Xhip has a sharp "blip" above 17k while the aJUNO is all over the place and can't self-oscillate.

Quite a thing to complain about a ten year old synthesizer not using enough CPU power for your liking

If you need a 24db low-pass filter, go use some other synth. Meanwhile Xhip will continue to sound the same as it has for over a decade.

(Also interesting to note the MS10, MS20 and so on with the KORG35 filter exhibit the same variation in resonance at high frequency, although these are 12db filters. Never heard anyone complain that the MS20 doesn't produce perfect sine sweeps.)

[aciddose]

Especially when there are methods like internal oversampling to achieve a sample rate the synth will work with, without teaching the customer how bad 44.1 is. So you really like to get rid of all the customers working with 44.1? Thats better than making Xhip work flawless for them?

Yes. Xhip does work flawlessly, you are just inventing an issue where there isn't one. This is exactly as intended.

Btw I can reproduce the Q bug with any sample-rate and any filter type, just the way I described Changing the filter trigger to "spike" makes it even worse, "reset" does the same buggy behavior. It's sad you didn't even try to investigate if it is a bug. You didn't ask me which sample rate I used or whatever, too. Just writing excuses - good support!

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? You know what, you have my condolences. You lead a tough life where stuff doesn't meet your expectations. Welcome to my world. The world. Reality.

The wav reading bug was definitely my fault. I used a normal 24bit file. Didn't know Xhip was that limited with handling files.

There is actually no such thing as a "normal 24-bit file". It isn't part of the RIFF WAVE standard. For 24-bit and other formats you need another file specification.

If Xhip were to support these files it would need to choose which type of encoding to use, for which there is no standard. It is better to NOT support such a thing rather than to cut corners. If you want to cut corners, there is a lot of other software that will do so for you. I think it is far more easy to convert your samples to a compatible format.

I could implement float (32bit, format = 3) support if it isn't already working. 24bit though isn't a standard. Is it packed into 32bits? Or does it break the microsoft WAVE standard by packing into three bytes? Is it signed or unsigned?

These properties can be "guessed" by the software but the thing about guessing is that the result isn't always correct.

You can't expect a program to accept invalid input data and make up for it somehow by guessing.

But theres the next problem - I don't know what the width is supposed to do on a custom sample. It just takes away the beginning of the sample!?

It sets the start offset for the sample on note-on. For example if you use a PWM sweep sample, pulsewidth acts as pulsewidth.

http://xhip.net/temp/wav/pulse_sweep_cut.wav

It'll work okay with this sample, although I turned the PW knob by hand so it isn't a smooth sweep. Still through the PW in Xhip maps pretty perfectly to the PW of the sample.