Riffer hold pedal/sustain when strumming

[SMAustinTexas]

Hi guys,
I've been spending some time using the riffer, which I really love, but I'm noticing some unexpected behavior between the strumming performance in the riffer itself vs when the riff is dragged to a host.

When a riff is playing in the riffer, a strum articulation holds the sustain for the duration of the entire riff (1 to 8 measures) until a new note is played on the same string later in the riff. This is unexpected, but I like it because then I don't have to draw out the notes to achieve the duration of the sustain that I want each time. If I need to end the sustain, I can insert a silent press articulation. If I draw in a few non-strum notes on the same beat to simulate a strum, the sustain lasts only for the duration of the note, long or short. Again...that's perfectly fine. Very workable.

The issue is when dragging the riff to a host (Cubase 9 in my case) and examining the sustain (CC 64) lane, the sustain is triggered on for the duration of the strum and then off at the end of the strum's duration, which is not how the riffer seems to be playing the strum. The result in the DAW version is that what sounds very smooth and connected when played in the riffer then sounds very choppy when played in the host. What I don't want to have to do is go back into my MIDI track in the host and hand draw the sustain durations to match the riffer's rendering. Make sense? I'll be happy to share my riff files and project with you if you want.

Is this behavior intentional? I think the main thing is to render the performance the same in riffer and in the host, which you have achieved almost perfectly.

Lastly, the other thing that is sorely missing in the riffer is being able to create a triplet rhythm within a non-triplet time signature. Other than that limitation, the riffer is brilliant. Nice work, guys.

[Eli [Ample Sound]]

Hi, thanks for your explanation. Currently, the difference between Riffer and host is an intentional design. The sound in Riffer is rendered with our internal engine, thus we can have the strum last until next note on the same string. But what you have said definitely makes sense, we'll consider to keep consistency in Riffer when dragged to host.

For the triplet rhythm, it is indeed an limitation in the current system. We'll see how can improve it in the future.

Hope it answers your questions and again thanks for the support. We will try our best to create a better user experience.

[SMAustinTexas]

Thank you, Eli, for the quick response. You answered my question. I did some testing and can confirm that the length of the sustain message (CC64) is not impacted by whether I extend the notes of the strummed chord in the riffer - meaning that to achieve the same rendering in the host I need to extend the sustain messages in my DAW, measure by measure. Not a huge deal, considering how much faster overall it is to build a guitar part using the riffer than to enter the MIDI directly into the DAW.

Perhaps you will consider allowing users to load a bank of riffs similar to a bank of chords and to be able to call different riffs by MIDI note? That way, for my project, I could just let Ample render the riffs and not have to fiddle with the MIDI. I know A#6 will trigger the currently loaded riff, but I'd like at least 24 riffs available to me in any one project. Possible?

Also, just noticing that the strummer on/off rendering when exported to the host isn't working like it does in the riffer. Another great reason to implement the idea above about pre-loading a bank of riffs.

[ghastlyshimmer]

They still haven't fixed this issue. Even with 3.5.0. Really bums me out. Rifferto piano roll is choppy af