This forum is now locked and moved (back) to Plogue's forum
  • First up - really diggin' Sfozando! Now, then:

    When the opcode


    ...the opcode


    ...ceases to function. No transposing of the pitch key tracking disabled sample is possible.

    Also, the opcode


    operates way - and I mean way - beyond the SFZ.1 spec of +/-100 cents! Like into the thousands! 

    Testing was done in comparison with the original RGC/Cakewak SFZ soft synth, in which the transpose remains active, and the "tune=" opcode is restricted to =/-100 cents.

    Sound like sfozando bugs?

  • davidvdavidv
    Posts: 453

    Hi first thanks for the reports!

    transpose=XXX not working when pitch_keytrack=0 makes total sense to me, and I wonder why its not behaving this way in SFZ.dll, probably Rene' processed both opcodes separately, treating transpose as if it were always 100 cents.  First time someone has tried that I guess. The way i interpret the spec is that transpose= is MIDI transpose, and pitch_keytrack tells you how many cents to move for each MIDI note. If you say the distance between notes is nil, logically transpose shouldn't do a thing

    But that is a very interesting discovery. If Rene' was still around, it would be an good question to ask him.


    tune=XXX is on purpose, I don't agree on limiting that to +100/-100 nor to add extra code to clamp it. Everyone likes to put their amp to 11 in case of emergencies. 

    I have pages of notes on what I dont agree with in the SFZ 1.0/SFZ 2.0 spec, and it mostly comes from doing an independent review/implementation of a separate engine.

  • pljonespljones
    Posts: 73
    My understanding of transpose was that it did exactly what it says: transposes the sample by a fixed number of semitones.  Similarly, tune should be used alongside transpose to fine-tune within a semitone.  These can be thought of as "in advance" of the triggering point - they apply regardless of the MIDI event that triggers the region.

    Key tracking, indeed, is different and applied after that initial adjustment, being applied at the time the sample is triggered, along with any other trigger-time adjustments (e.g. sfz 1.0 "pitch_random").  Key tracking is only relevant, of course, where the region is triggered by a note on (rather than a CC event).  Transposition would apply in any case.

    Further real-time pitch adjustment, after triggering, should also be independent of key tracking, such as pitch wheel adjustments and any EG/LFO adjustments in place.
  • davidvdavidv
    Posts: 453
    I just need to check on all our released SFZ file if decoupling transpose and pitch_keytrack can be easily done. 
  • davidvdavidv
    Posts: 453

    Check complete, no instance of transpose!=0 and pitch_keycenter!=100 found in any of our products.

    WIll change this in next official build of aria

  • Great!

    Just to make sure:

    The issue raised was transpose=XXX with:




  • davidvdavidv
    Posts: 453

    Erm you are absolutely right.

    To make things clear both opcodes are concerned.

    The ARIA code previously was something like

    basePitch = ((MIDI_NOTE+transpose)-pitch_keycenter) * pitch_keytrack;

    But now its more like:

    basePitch = (MIDI_NOTE- pitch_keycenter) * pitch_keytrack;

    and transpose dealt with after, with about 16 other independent things which influence the pitch of a voice.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!