The Quilcom Harpverb: A stringy kinda sound...

[Spogg]

Hi to all you lovely flowstoners!

The Quilcom Harpverb was inspired by Pianoverb and Sympathizer but is, of course, my own take on such an effect system.

The original idea was to simulate the sound of a harp or piano, with the sustain (damper) pedal pressed and when excited by an input signal. This gives a chromatically tuned type of sympathetic reverberation.

Having made the basic engine (using 61 tuned resonant comb filters) I quickly realised that it was easy to tweak the settings to provide a surprisingly wide range of weird and interesting variations on the basic idea. I actually don’t know how you could create some of these sounds by any other means!

I made a video to demonstrate some of these sounds, based on the inbuilt presets:

https://youtu.be/RYwKQcZl7rA

The effect has a MIDI input so you can use your sustain pedal along with a piano synth to add the sound of sympathetic string resonance when the pedal is pressed. It can, if you so wish, also use the last note pressed to shift the whole span when playing.

The download includes the fsm, VST, presets and a User Guide:

https://www.dropbox.com/s/zu7ecuplx03et ... 5.zip?dl=0

I hope you have a bit of fun with this and maybe find a creative use for it.
As always, comments are most welcome.

Cheers

Spogg

[gvalletto]

Good job, spogg. I made years ago a hardware DIY synth. It had a very basic envelope module with no Release stage. This FX can supply that lack. Wheter i build a new one, i will use it with Harpverb.

[Spogg]

Thank you!

It’s an unusual and rather niche effect, so I’m very glad if you find an application for it.

Cheers

Spogg

[trogluddite]

This is a wonderful effect, Spogg; excellent work - and a beautifully clear GUI, to boot!

I've always been a fan of PianoVerb, but I think that HarpVerb may replace it from now on, as it is so much more controllable (especially being able to restrict which notes are used, and the various panning modes). Like gvalletto said, "tuned reverbs" are great for "pad-ising" sounds with too little sustain and for creating abstract atmospheric drones, so it will be perfect for my bass-guitar looping music (my keyboard playing is terrible, so I love anything that can make my bass sound like a different instrument.)

Loved the video, too. I always test my FX by having a microphone plugged in - much to the amusement (or irritation!) of my landlady in the room downstairs, who wonders why she can hear me "speaking in tongues" when I'm all alone! Having said that, having the built-in harp and impulse generator is a very neat touch to ease the making of new presets.

[Edited In]
Looking at the schematic (very neat and clear BTW), one little tip comes to mind. Inside the '61 Harp strings -> Chords' section, you have a lot of code boxes with unused outputs. I would eliminate these if you can, as each one will have a memory address allocated to it.

It's not that the increase in memory size is huge, but it means that more data has to be loaded into the CPU caches from main memory, due to the caches always requesting data in contiguous chunks containing multiple bytes (in this case, many of them meaningless). Reading/writing a cached memory address is very fast, just a few clock cycles, whereas requesting a new cache line from main memory is far slower, possibly hundreds of cycles. This is always worth remembering when optimising DSP/Assembly - how data is arranged in memory can have a far bigger influence than a few stray opcodes. Data that is accessed together should always live as close together as possible - pack them in like sardines in a tin!

Having said that, I don't think that this little niggle will be costing you huge amounts of CPU; in general you've done things very efficiently.

[Spogg]

High praise indeed Trog. I’m very flattered.

For me, the most important comment you made is about the GUI. I do try my best and I’ve been offered a lot of generous help and advice, especially from tulamide. But I have no natural talent regarding graphic and GUI design. It’s a bit like buying paints, brushes and a lovely canvas and studying the old masters, and then expecting to be able to turn out similar stuff. That may be a silly analogy but that’s how I feel about the subject.
Thankfully your comment has encouraged me no end.

Plus, you’ve answered a question I did wonder about, namely unused streamouts in DSP.
My thinking was that they do nothing so probably don’t consume CPU. Those chord things, as you can see, were based on a template which I simply edited according to the required function per DSP box. I shall mend my ways in the light of this note.
One thing I would ask though: Since this is running in blue, the unused streamout outputs would only be loaded once wouldn’t they? Or are they loaded/addressed on every sample?

Cheers

Spogg

[wlangfor@uoguelph.ca]

Great, I'll give it a try, thanks Spogg

[BobF]

Hello Spogg,

A very cool effect, I will probably use this a lot. Very nice layout inside also. I guess your next project could be that "Harpverb", ha, ha.

Great work as always. Cheers, Bobf.....

[trogluddite]

Since this is running in blue, the unused streamout outputs would only be loaded once wouldn’t they? Or are they loaded/addressed on every sample?

In main memory, the space will be allocated once, so each streamin/out keeps the same address every time it's accessed. The CPU caches are more complex, though, as they generally have a lot less space to play with - 'lines' of main memory data are loaded and discarded as necessary to make best use of the cache space. Cache lines will get discarded to make space when necessary, leaving whatever was there before needing to be reloaded from main memory at the next access.

It's pretty much impossible to know when a cache line might be required for something else, as the CPU is free to switch between processing different threads whenever it likes, with no heed paid to "boundaries" in the code such as functions or loops.

A list of streamin/streamout is very likely to be allocated contiguous memory addresses when you declare them, so the "unused" addresses mean that more cache lines need to be loaded in order to have a given amount of "useful" addresses available in the cache at any given time.

This is a good reason to always test CPU loads in a typical project setting rather than in isolation, as the amount of demand on the caches will depend on the sum total of processes that are running on a given CPU core. I find Reaper really handy for this, as it can show per-channel CPU loads as well as the overall figure.

However, you are correct in principle. Modern CPU caches have all sorts of complex logic which tries to predict which cache lines you're using the most, and even to notice that you're stepping linearly through a set of addresses. So a 'fixed' address such as a streamin/streamout is likely to be less of a problem this way than, say, a database that has it's data badly structured. Incidentally, this is also another reason that mono4 is so efficient, as the four elements are guaranteed to be contiguous block of addresses which will never straddle a cache line boundary.

[Phil Thalasso]

Hello you all and thank you Spogg.

This is another great instrument with plenty to learn from inside. By chance you picked my old state-side high-school colors for your new corporate design. Maximum contrast and a very carefully arranged interface. Great job.
Sound-wise it is a class of its own. I know of no other reverb that can deliver that range of effects. Have a nice sunday!

Best Regards
Phil

[Spogg]

@Trog:
Many thanks for your explanation. To sum it up would “…well, it depends…” be an appropriate view?
One thing that I feel certain of is to avoid unused outputs (and inputs) in a poly stream for sure.

One day I’ll play Spot the Difference and delete all of those streamouts and try to get a handle on any CPU reduction.

I take note of the FS CPU meter of course, but I also check with Reaper and the Windows Task Manager, with and without the plugin plugged in.
The Task Manager has helped me locate some horrible Ruby code I once made which simply ran wild all the time. 12% constant CPU on my core i7 system, and for nothing. The FS CPU meter gave no clue. Also excessive triggering shows up well in the Task Manager. It taught me I had to be careful with the modwheel output for example.

This gives me a great opportunity to thank you big-time for your Trigger Tutorial I found ages ago. It explained so much to me.

I know you’re not into the idea of playing with FS4 but one thing I’ve used it for is the CPU meters which show audio thread and overall CPU separately. It also has a wonderful trigger counter which registers the amount of triggers per second for the whole schematic. That helped me to reduce the CPU by only allowing the Vu meters to run when there is a useful audio signal present.

@Phil:
I really appreciate your positive comments, especially about the GUI. That means a lot to me!
I have to tell you that it was tulamide who decided on the core colour scheme and he also designed a range of new logos for me. I am very grateful to him.

Cheers

Spogg