When the user records some new clips we’d like to identify and remove any clips that are under the newly recorded clips.
Is there an easy way to do this?
I’m guessing add a change listener to transport so we pick up when recording stops. But how to identify which are the new clips and which are the original clips prior to recording?
I can’t find much useful in the examples.
The input devices support this. See
WaveInputDevice::setMergeMode. I can either be overlay, replace or don’t record.
Oh thanks Roland - that’s pretty great - although the app then needs to mirror the changes over an API so we need to track down what was done and send a kind of change log.
I’ll check it out
void setMergeMode (const juce::String&);. What was wrong with an enum?
Yeah, that isn’t great. I’m guessing it’s ancient code that should be updated.
Quick question from a users perspective.
Would you prefer:
a) Removing the existing function taking a string and replacing it with an enum version, forcing a compile error and hence you to update?
b) Adding the new function taking an enum and marking the old one as deprecated? (Probably causing a warning and if you have Werror enabled a compile error anyway)?
c) Do nothing and keep existing code compiling?
@dave96 my vote goes for option “a”.
Should be very easy change on users side.
d) add new function. Strongly suggest in the comments to use the new function and leave the old one there. Thus avoiding the warning for code that already works but providing a nice clean interface for new code?
e) return a new object convertable to a string but which is secretly an enum on the inside?
Tbh I’m leaning in favour of a). In these situations I tend to try and think what the API should be like rather than how to fudge compatibility with the existing one as that almost always leads to the cleanest code and is easiest to test and maintain…
definitely a), for the compile error + revisiting code around it.