Ribs

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

Our pleasure, 1eqinfinity :)

Would a crossfade be better than a dip?
  • Again, the fades would only be registered by the playhead.
  • A fade out would occur on the newly written content, ending at the write position.
  • A fade in would occur on the previous buffer, ending at the write position.
x-fade.png
You do not have the required permissions to view the files attached to this post.

Post

1eqinfinity wrote: Wed May 01, 2019 5:48 am Nice one too! That would work if the time the record head reaches the playhead is bigger than the time when the played "to be damaged" grain ends. But long grains will have clicks anyway, and starting long grain in a different position in general would be noticeable.

I really appreciate your ideas, guys! :)
In my own experiments I have never clicks in long grains. But I use for those fixed (small) fade-in and fade-out times and keep the long part at full volume... My proposal would change the grain size if start or end point of a grain would come across the record head as there always would be a click. It would just avoid that that click will ever be inside a grain...
It could be noticeable, but that would not hurt as much as clicks. The movement would stop if the grains are small, and then jump to a different time point to the other side of the record head. But that sound change would be expected anyway. If you wanted to blur that, you‘d need to go into the FFT world and blur sudden spectral changes which is a completely different thing...

Post

levendis wrote: Wed May 01, 2019 6:35 am Our pleasure, 1eqinfinity :)

Would a crossfade be better than a dip?
  • Again, the fades would only be registered by the playhead.
  • A fade out would occur on the newly written content, ending at the write position.
  • A fade in would occur on the previous buffer, ending at the write position.
x-fade.png
If I got your idea right, essentialy you're suggesting a shadow buffer.

Post

Tj Shredder wrote: Wed May 01, 2019 1:21 pm
1eqinfinity wrote: Wed May 01, 2019 5:48 am Nice one too! That would work if the time the record head reaches the playhead is bigger than the time when the played "to be damaged" grain ends. But long grains will have clicks anyway, and starting long grain in a different position in general would be noticeable.

I really appreciate your ideas, guys! :)
In my own experiments I have never clicks in long grains. But I use for those fixed (small) fade-in and fade-out times and keep the long part at full volume... My proposal would change the grain size if start or end point of a grain would come across the record head as there always would be a click. It would just avoid that that click will ever be inside a grain...
It could be noticeable, but that would not hurt as much as clicks. The movement would stop if the grains are small, and then jump to a different time point to the other side of the record head. But that sound change would be expected anyway. If you wanted to blur that, you‘d need to go into the FFT world and blur sudden spectral changes which is a completely different thing...
FFT would be too much since I need a per-buffer declicking.
I think that a shadow buffer could be the solution. But I don't want to change the grain size since it will break the rhythmic pattern in BEAT mode, for instance.

Post

1eqinfinity wrote: Sat May 04, 2019 6:50 pmIf I got your idea right, essentialy you're suggesting a shadow buffer.
Indeed, as you proffered prior to me doing so.
At first, i perceived a shadow buffer would be the previous (filled) buffer, the one read from. The current buffer inaccessible to the playhead. i wanted to suggest a way of having the current buffer playable too. So the clarification is appreciated, thanks.

Post

levendis wrote: Sat May 04, 2019 7:25 pm At first, i perceived a shadow buffer would be the previous (filled) buffer, the one read from.
It could be just a copy of a previous buffer, but it can be too expensive to copy 2 seconds of data (2 * 2 * 44100 samples). Idk, one should always measure the actual performance. The other option is take the current playhead speed and the refill speed, compute the play and record heads crossing point, and copy ~100 milliseconds from that point, again, taking into account the playhead speed. I simplified the process a lot since one has to care about the changes of all the parameters involved :)

Post

1eqinfinity wrote: Sat May 04, 2019 6:54 pm But I don't want to change the grain size since it will break the rhythmic pattern in BEAT mode, for instance.
Instead of changing the grain size, you could zero pad the part which would reach across the border. That would not change the timing... Little drop outs hurt less than clicks...

Post

The clicks in BEAT mode aren't so bad, given they become part of the tempo. Unless the play position is automated.
Somewhat uncomfortable is if the buffer isn't a snug ratio, in other modes. With a static read position, the buffer length becomes the period between clicks. If the buffer length is not 'tuned', then the click period stands out more, as it isn't to tempo.
When using jump to buffer start on each note is active, for both read and write position, the click is also palatable as it sounds like the attack transient of note events.

This quirk won't stop me using Ribs. It's great at what it does!!!

Post

briandc wrote: Thu Jun 29, 2017 10:17 pm +1 for a linux build, 32-bit as well. ;)

brian
I agree and would like ask if this is possible - is it? maybe someone here can help with that?
thank you!

Post

Tried this out and it has quickly become one of my favourite VST's! It took a few hours to learn what was going on, but it was well worth it for the lovely sounds it can create.

It looks great too. I installed the font on my windows pc but it still didn't show up in Ribs. Maybe it needs to be in the same folder as the dll file? No big deal for me, as I have memorised the parameters anyway.

I like the fact that you can't save buffer contents. It is by its very nature an unpredictable synth, and capturing the moment seems the best way to treat it, in my opinion. There are almost acoustic sounding sweet spots which happen in the moment which I live for, recorded or not.

Great work on this one!

Post

Tj Shredder wrote: Sun May 05, 2019 1:20 pm
1eqinfinity wrote: Sat May 04, 2019 6:54 pm But I don't want to change the grain size since it will break the rhythmic pattern in BEAT mode, for instance.
Instead of changing the grain size, you could zero pad the part which would reach across the border. That would not change the timing... Little drop outs hurt less than clicks...
Hmm, interesting idea, thanks!

Post

udaemon wrote: Mon May 06, 2019 2:19 pm
briandc wrote: Thu Jun 29, 2017 10:17 pm +1 for a linux build, 32-bit as well. ;)

brian
I agree and would like ask if this is possible - is it? maybe someone here can help with that?
thank you!
Unfortunately it's not likely possible, since my current working schedule makes it hard to find time to develop for existing builds :/

Post

Muied Lumens wrote: Tue May 07, 2019 2:39 pm Tried this out and it has quickly become one of my favourite VST's! It took a few hours to learn what was going on, but it was well worth it for the lovely sounds it can create.

It looks great too. I installed the font on my windows pc but it still didn't show up in Ribs. Maybe it needs to be in the same folder as the dll file? No big deal for me, as I have memorised the parameters anyway.

I like the fact that you can't save buffer contents. It is by its very nature an unpredictable synth, and capturing the moment seems the best way to treat it, in my opinion. There are almost acoustic sounding sweet spots which happen in the moment which I live for, recorded or not.

Great work on this one!
Thanks! :) I agree on the unpredictability, but at the same time sometimes it's painful to discover that the record was off.
The fonts should just be installed in the system. However, if you're on MacOs there might be problems with loading the fonts.

Post

1eqinfinity wrote: Fri May 10, 2019 9:24 am Unfortunately it's not likely possible, since my current working schedule makes it hard to find time to develop for existing builds :/
I very understand that!
and let me say "thank you!" for writing and publishing this wonderful plugin. it's really good!

Post

udaemon wrote: Fri May 10, 2019 3:16 pm
1eqinfinity wrote: Fri May 10, 2019 9:24 am Unfortunately it's not likely possible, since my current working schedule makes it hard to find time to develop for existing builds :/
I very understand that!
and let me say "thank you!" for writing and publishing this wonderful plugin. it's really good!
Thank you for your feedback :)

Post Reply

Return to “Instruments”