Coming out of the Deluge read/write (#152) and the Deluge→Quantum/Iridium modulation work (#161): the one musically-significant thing that currently can't survive a conversion between two arp-capable devices is the arpeggiator.
Today CWM carries no arp data at all — the model has no concept of it, and the few creators that touch arp parameters (Disting EX, Yamaha YSFC) just write them to off/neutral defaults. So a Deluge "Arp" preset converts to an Iridium patch as a plain held multi-sample and the arp is silently dropped.
Before writing any code I'd like to gauge whether you'd accept adding an optional arpeggiator descriptor to the model, populated only by formats that support one.
Model — a small optional value object (absent by default), roughly:
- mode (off / up / down / up-down / random / as-played / chord …)
- octave range
- rate — tempo-sync division and/or a free rate
- gate length
- on/off (and maybe swing)
Formats with no arp simply ignore it; formats that have one read/write it.
Read — the Deluge stores it directly, e.g. <arpeggiator mode="up" numOctaves="2" syncLevel="6" /> plus arpeggiatorGate / arpeggiatorRate. Straightforward to populate.
Write — Quantum/Iridium (the .qpat named-parameter list already used in #161 extends cleanly), and the formats that already reserve arp slots (Yamaha YSFC, Disting EX) could fill them instead of zeroing them.
A few questions for you:
- Is an arpeggiator descriptor in-scope for CWM, or do you consider it performance data that should stay out of a multi-sample converter (the way LFOs currently do)?
- If in-scope — would you prefer it on
IMultisampleSource, or only on the performance / IInstrumentSource side?
- Any enum/shape preferences so it matches the existing model conventions?
If you're open to the model addition, I'm happy to implement the Deluge→Iridium path end-to-end — I have the hardware to reverse-engineer the Iridium arp parameter names and calibrate the rate/mode mapping, same approach as the modulation work.
Coming out of the Deluge read/write (#152) and the Deluge→Quantum/Iridium modulation work (#161): the one musically-significant thing that currently can't survive a conversion between two arp-capable devices is the arpeggiator.
Today CWM carries no arp data at all — the model has no concept of it, and the few creators that touch arp parameters (Disting EX, Yamaha YSFC) just write them to off/neutral defaults. So a Deluge "Arp" preset converts to an Iridium patch as a plain held multi-sample and the arp is silently dropped.
Before writing any code I'd like to gauge whether you'd accept adding an optional arpeggiator descriptor to the model, populated only by formats that support one.
Model — a small optional value object (absent by default), roughly:
Formats with no arp simply ignore it; formats that have one read/write it.
Read — the Deluge stores it directly, e.g.
<arpeggiator mode="up" numOctaves="2" syncLevel="6" />plusarpeggiatorGate/arpeggiatorRate. Straightforward to populate.Write — Quantum/Iridium (the
.qpatnamed-parameter list already used in #161 extends cleanly), and the formats that already reserve arp slots (Yamaha YSFC, Disting EX) could fill them instead of zeroing them.A few questions for you:
IMultisampleSource, or only on the performance /IInstrumentSourceside?If you're open to the model addition, I'm happy to implement the Deluge→Iridium path end-to-end — I have the hardware to reverse-engineer the Iridium arp parameter names and calibrate the rate/mode mapping, same approach as the modulation work.