This forum is now locked and moved (back) to Plogue's forum http://plogue.com/phpBB3/viewforum.php?f=14
Amplitude envelope release affected by different group...?
  • Hey all,
      I'm trying to emulate a stringed instrument with a single string for lead notes and a group of 3 other notes for strumming. I have something like this in Aria:

    <group>  //main lead notes
      polyphony=1
      group=0
      //off_by=0
      //off_mode=fast
      ampeg_release=10
    ....
    <group>
    //strum notes
      group=4
      ampeg_release=10
      lokey=120 hikey=120 pitch_keycenter=61 sample=MyStrumSample.wav
      <region> transpose=-60 delay_beats=0       stop_beats=0.125
      <region> transpose=-53  delay_beats=0.09375 stop_beats=0.25
      <region> transpose=-48  delay_beats=0.1875  stop_beats=0.375


    Expected behavior: 
    • In normal playing, group 0 is involved, and it emulates a single plucked string; i.e. there's a long release after note off, which is choked if a different note is played.
    • When note 120 is received, group 4 emulates 3 notes that are 'strummed'
    The issue:
    • If the strum notes (group 4) are not played, group 0 behaves as expected, with long release after note off.
    • However, when the group 4 notes are played, the release of group 0 is immediately choked!
    I've tried off_by (commented above), and the effect is the same. I've tried polyphony=48 globally, and still the issue persists.

    Any help in resolving this would be appreciated...! For the instrument I'm emulating, it's important to have the long release on the main string while the strum notes are played.

     - Guru
  • I must clarify: when the strum notes (group 4) are played, the lead note (group 0) is not choked off itself; rather its release setting gets changed. So if I keep the key pressed, the note continues, but upon noteoff, there is no release heard!

    Which makes me think this is not an issue of polyphony, but perhaps some bug in the engine? I hope not!
  • davidvdavidv
    Posts: 453

    Hi

    For complex issues like this I think from now on we are going to require a minimalistic sfz file only containing internal generators to reproduce the behaviour. 

    example

    <region>

    key=30

    sample=*sine

    <region>

    key=50

    sample=*noise


    etc. Please make a simple SFZ file which we could directly test. you are also using (...) which implies the file is probably more complex and there might be interation with other opcodes that we cant see.


    Thanks

  • I see your point, it would be fair for me to provide a minimalistic file in its entirety here. It might take some time, though (I'll have to lookup how to use *sine!). Will post as soon as possible.
  • davidvdavidv
    Posts: 453

    *sine, *noise and *silence are supported by Dimension Pro and ARIA. 

    Aria supports other generators starting with * like *tri, *saw

    Basically you can treat a * generator as a sample that has pitch_keycenter=60 (unless you change this default)

    "<region>sample=*sine" is in fact the simplest SFZ file you can make, and a quick way to start a test without requiring external files.


    NOTE Rene and I didnt agree on the root pitch of internal generators, while mine follows pitch_keycenter, rene's *sine is 440Hz, and i dont know how it reacts to pitch_keycenter.

  • A sine wave has a frequency.  What's the frequency of *sine?

    pitch_keycenter just says "do not repitch the waveform when the key is x" for "pitch_keycenter=x".  The default pitch_keycenter is 60.  Saying the frequency follows pitch_keycenter literally means that the frequency will not get repitched.

    I was going to say René had this covered -- A440 tuning -- but I'm struggling to work it out...
  • davidvdavidv
    Posts: 453

    There is no internal waveform in the ARIA binary, its synthesized on the go, so there is no base frequency.

    The frequency of ARIA's oscillator is taken from the current pitch_keycenter of the region hence why if you leave it to the default  pitch_keycenter=60 (261.6255798Hz) It will be in tune.

    You don't have to Know its 440 or anything silly. 

    if you want to use Rene's *sine and make it in tune, you have to check for the midi note for 440 and manually add it like:

    sample=*sine pitch_keycenter=69

    I feel my method is more intuitive and transparent, but i might be somewhat biased.

  • Sorry, I don't understand "check for the midi note for 440" -- MIDI has no frequency information (it does have relative pitch, if you're treating the notes as such - i.e. subject to pitch_keytrack).  What

    sample=foo.wav pitch_keycenter=69

    means is "if you get MIDI note 69, play foo.wav without repitching it".  It tells you nothing about the frequency/-ies of foo.wav.  Intuitively, sample=*sine would work the same way.  I'd expect

    sample=*sine pitch_keycenter=69

    to play *sine at its default frequency when MIDI note 69 is played.

    Thus, if I have

    <region> lokey=0 hikey=10 pitch_keycenter=5 sample=*sine
    <region> lokey=117 hikey=127 pitch_keycenter=122 sample=*sine

    Then playing note 5 and playing note 122 will have the same frequency -- but I've no idea what frequency, as it depends on the frequency of *sine and I don't know what that is.

    From what you're saying, *sine would get repitched to be some function of the incoming MIDI note and the pitch_keycenter - is that right?
  • davidvdavidv
    Posts: 453

    I'm fully aware of the role of pitch_keycenter for samples, but this is not a sample. makes no sense to me to list it somewhere as a virtual sample and give it a value in Hz, its an oscillator and an oscillator can be played at any frequency.

    to reply "*sine would get repitched to be some function of the incoming MIDI note and the pitch_keycenter - is that right?" 


    For 99.99% of uses in the past 30 years, MIDI note 69 was thought of being 440Hz. And so so forth for all MIDI notes:

    http://www.phys.unsw.edu.au/jw

    So its not just _some random function_

    Since base detune in cents is ((NOTE-pitch_keycenter)*pitch_keytrack), if the frequency of the oscillator is internally set to the standard equal temperament value for the midi note set in pitch_keycenter, then you don't have to care, the oscillator will always be in tune with regards to the input MIDI note, unless of course you use transpose/tune/bend and any other pitch mods

  • davidvdavidv
    Posts: 453
    A simpler way to see it is that there is no sample and you are building one on the fly by giving it its pitch_keycenter.
  • I think I get what you're saying -- you need a way to specify the frequency for *sine and you've taken pitch_keycenter to do that.  So in the example I gave, the two notes would have different pitches, because they had different pitch_keycenter.  If I'd replaced *sine with a sampled sine wave, they would have sounded the same, of course.  That's what's confusing.  I guess I think it might have been clearer to add a "frequency=X" opcode to set the oscillator frequency.
  • davidvdavidv
    Posts: 453

    To keep the simplicity and not to break my current synths, I don't mind adding sample_freq=X

    as long as it defaults to the value of middle C on the equal temperament scale which is 261.626Hz

    why not frequency=X? I want to make it clear it targets the sample (or generator). And I already have got 3 other similar ARIA extensions (sample_const_paramX=Y sample_dyn_paramZ=W and sample_config=TEXT

  • davidvdavidv
    Posts: 453

    The interesting thing that I just looked over this morning is that Rene's own oscillator=on/off opcode (which takes the sample in sample= and transforms it into a wavetable oscillator) doesn't mention base pitch either. We will look into this now.

    EDIT after testing Rene's wavetable are middle C as well, and respond like you expect with regards to pitch_keycenter, so changing this on my end to match it.

  • As I see it, the only important difference between sample=*sine and sample=mySineWave.wav is the former have no notion of frequence or amplitude. Isn't the most obvious way to adress this situation just to give it that? Like sample=*sine_440_70.

    This way you neither have to introduce additional op codes valid only for internal generator sounds nor have to reinterpret the meaning of current op codes when used together with *sine et al.

    Another benefit is you can easily do search and replace edits of your sfz file for testing/debugging/templating etc, by searching for "sample=nnn".

    Well, when thinking a bit more about it, I think *sine_C4_70 would be even better, reducing the need for exhausting manual conversion between frequencies and note numbers/names.

    What do you think?

    And as you've already realised, _70 stands for the amplitude in percent of the max volume (0 dB?) of a sample file. Could be optional of course if you don't care about the change in volume when altering between real samples and generators.
  • davidvdavidv
    Posts: 453
    Well one thing is that the current method wont change since its already in use by our free bank and chipsounds. while sine_440_70 looks nice, you still have to support cases where the frequency is like 232.32453434590 and amplitude is 70.1234513409, which on top with tokenisingthe "_" charater makes for a difficult to support parsing scheme
  • Hmm, I can hardly make any sense out of what your saying. At all. Why would 232.32453434590 be hard to parse?! or 70.1234513409? either alone or concatenated with an underscore? You split the sine op code value by the underscore and whips, you have your two float values. It can hardly be any more difficult than with any other legitimate floating point/percentage value like amp_veltrack for instance. If anyone should ever need that many decimal places for the amplitude. Or the freq. I guess most would be satisfied w like c#4 for the frequency. And like 67.8 for the amplitude

    And why would that break any current implementation? You could still use bare *sine with whatever default your accustomed to.
  • davidvdavidv
    Posts: 453

    Its an ugly string that is all. why put more than one variable per opcode unless you absolutely have no choice?

    Also why do you guys care so much about this when clearly anything that comes after sample=* is engine dependent. ARIA does its thing, Dimension Pro does its thing.

    If you do <region> sample=*sine or any oscillator, you don't have to do anything, it will be, by default in tune to MIDI. if you want to change it, I added an ARIA extension called "sample_freq" in the next build.


Howdy, Stranger!

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