The future of SFZ in MuseScore
I was wondering whether Werner had any plans for increasing the number of SFZ opcodes which Zerberus recognises.
If not, maybe this would make a good GSOC project?
It would be good to bring Zerberus up to SFZ 1.0 compatibility in the future.
Comments
I don't have concrete plans for any work on the zerberus synthesizer. It would be a nice project to make it work with other sfz files.
ChurchOrganist or others, is there any specific opcodes or specific SFZ banks that you would like to use with MuseScore?
In reply to ChurchOrganist or others, is by [DELETED] 5
I think the most important ones are.....
loop_start
loop_end
pan
width
position
ampeg_attack
ampeg_hold
ampeg_decay
ampeg_sustain
In reply to I think the most important by ChurchOrganist
I'm interested to work on this topic for GSoC 2016!
What do you think how important are pitch lfo related opcodes and all that filter stuff?
In reply to I'm interested to work on by hpfmn
I don't think they're really relevant to the production of soundalike instruments such as those used orchestrally, or for instruments like acoustic guitar and basses etc.
Where you want control over them is when you are producing SFZ synthesiser sounds.
Having said that, it would be useful to be able to get Zerberus to respond to the the Mod Wheel, or maybe polyphonic aftertouch so vibrato would be possible.
I have listed the really important ones above - if we could start with those, then the exotic stuff would come later.
The really vital one is to get Zerberus to respond to loop points defined within the sample.
I have done some work on how these are defined within a RIFF wave file, but the problem is that the RIFF format is too open and I don't yet understand how the cue points chunk which holds the loop points data really works as different WAV samples use different ways of storing it - eg some WAV files store the loop points at the end of the file and some as part of the header.
In reply to I don't think they're really by ChurchOrganist
Why do you have to define loop points in the wave file? I thought for sfz they would be defined in the sfz file itself?
Thanks for your reply so far!
In reply to Why do you have to define by hpfmn
You have to be able to deal with loop points saved in the wav file because the default behaviour of SFZ is to use any loop points found there.
I quote from the loop_mode definition in the SFZ spec......
loop_mode
If loop_mode is not specified each sample will play according to its predefined lopp mode. That is, the player will play the sample looped using the first defined loop, if available. If no loops are defined, the wave will play unlooped.
The loop_start and loop_end opcodes are there for overriding loop points defined in the sample.
Davy Triponney, the author of Polyphone may be able to help with the RIFF format as Polyphone reads (and writes) loop points in imported/exported samples.
In reply to You have to be able to deal by ChurchOrganist
Ahh ok!
Since MuseScore uses libsndfile to deal with audio files - why not use their loopinfo? http://www.mega-nerd.com/libsndfile/command.html#SFC_GET_LOOP_INFO
Not sure if they cover all methods of looping a file though... and if that info is what we really need...
Maybe having a look at Polyphones source is enough. But thanks for enlighten me about the sfz spec ;)
I think polyphone gets its info in trunk/sf2_core/sound.cpp starting at line 643.
In reply to Ahh ok! Since MuseScore uses by hpfmn
So polyphone is using the "smpl" chuck of a wav file! Above I sadly linked to the wrong part of libsndfile.
So we want to use http://mega-nerd.com/libsndfile/command.html#SFC_GET_INSTRUMENT
(which also gets its information from the "smpl" chunk)
In reply to So polyphone is using the by hpfmn
That's great :)