Weekly status update June 27th to July 3rd

Posted 8 years ago

Hi,
midterm is over and we have to see what will happen in the rest of the time. I think I already reached more than I expected (even though I knew that what I was reaching for was very low to make sure I'll reach that without any hassle).

This week got some new opcodes (I think and hope this will happen for every week from now on!):

  • on_hiccN/on_loccN - adds the possibility of playing back samples base on certain CC Midi events (this is used for the pedal samples in salamander)
  • ampeg_vel2* - this makes it possible that the velocity of a note can change the amp envelopes it is used quite some bit by SSO for example and makes the sound a lot more vivid!
  • rt_decay - this works together with the trigger=release samples, it tells the synth how much a release sample should be attenuated based on how long after a note on events the note off happens - this makes the hammer off/harmonics on release of salamander fit in much better with the normal note on sound

All these new opcodes are supported in the master branch - so as last time you can just download a nightly build for you platform and try it out!

What also made it into the master branch is a better parsing of the sfz files. In general the parser structures the opcodes by the equal sign. If it finds an equal sign it assumes the part in front of it (after a white space) is an opcode and the part after is its value. But SalamanderV3Retuned.sfz sadly has a malformed part from line 449 to 464. The tune opcode is missing its equal sign. So the pitch_keycenter didn't get recognized because Zerberus thought that the tune part was still part of pitch_keycenter's value.

Since only path and sample definitions could have white spaces in their opcode value I split the opcode value string by white spaces and just use the first part of it. So at least pitch_keycenter gets parsed right in this case! (tune however doesn't work - but I don't think that is good to tolerate too much errors in a sfz file!)

Changes that are on their way are the whole control-section. So you can set a default_path for samples, define note and octave offset and also use some macro stuff with the #define statement. Where I'm not sure currently is the set_ccN opcode this initializes a Midi CC to a start value. But I don't know what would be the expected behavior if you have multiple control-sections - actually that doesn't make sense to have different initial CC values for different parts of a file - but in most files I've seen so far have just one control section at all. But I also plan on implementing #include statement which is an addition by the aria-engine. And the files using this often include files that have a control section each. So I'll have to do some testing/researching in that field how the synths like linuxsampler, aria or sforzando handle these cases. I also want to investigate on the global-section in combination with include. So expect a big update on meta-sfz features!

Speaking of CC messages - I also plan to change the behavior of CC in MuseScore in general. Currently CC messages are just issued by special lines/spanners - in the stable versions actually just by the pedal line - in my experimental version also by slurs (for legato) and hairpins (for single note crescendo). But lasconic had the idea to generalize this and also give you the possibility of adding some midi CC events by spanners. (Currently you could add some by midi action text) So I plan to add the possibility of issuing midi CC by all spanners!

There should by these main modes of operation for CC messages:

  • switch - like the piano pedal or legato pedal
  • continuous - smoothly changing values over time
  • continuous with play event bounding - values change smoothly but the is always a event created on each note on
  • play event bound - just create events during note on

Then you should be able to just enter a CC number of your choice a start and an end value and you're good to go. Things like the piano pedal line would have the respective default of course. But you would also have the possibility of creating a soft pedal line or changing of the vibrato effect over time etc., etc.

I think opcode wise a lot of the popular free-sfz file opcodes are supported - so I hope to show you the new additions with salamander and SSO soon. But I also hope we can have even more opcodes in field of pitch related things, lfo and after that some of the filer stuff. I don't know if I will be able to touch some of the effects - maybe it makes more sense to have vst/lv2 support in the long run, but I think that is something that might happen after GSoC.