bb.linuxsampler.org

A quick question.

Is there a list of currently supported opcodes for the sfz engine?

I'm trying to use the "offset" opcode, and it doesn't seem to be working, given i'm not trying to make a user error here somewhere.

Alex.

Just to be clear: It is really early days for the sfz engine, basically the only thing it currently do is triggering samples. The impressive work Grigor have done is to refactor the GIG engine code so that it can be reused by the new SFZ and SF2 engines. It was all committed to CVS as it started to become a bit messy sending patches between developers for review via email, not because they were ready for release. I think Grigor is currently implementing the EGs and LFOs.

Currently the LinuxSampler SFZ Implementation document is more of a wish list of opcodes to be implemented and source for figuring out what each opcode is supposed to do. It will hopefully soon start to reflect the reality once more work have been done on the engine. Just because the SFZ reader at the moment manage to parse a definition file and recognize an opcode doesn't necessarily mean the opcode has yet been implemented in the SFZ engine.

Hmm.. just took a look at sfz.cpp and it looks like the "offset" opcode isn't parsed at all while both "offset_random" and "offset_onccN" are. So at least that omission is a bug.

dahnielson wrote:Just to be clear: It is really early days for the sfz engine, basically the only thing it currently do is triggering samples. The impressive work Grigor have done is to refactor the GIG engine code so that it can be reused by the new SFZ and SF2 engines. It was all committed to CVS as it started to become a bit messy sending patches between developers for review via email, not because they were ready for release. I think Grigor is currently implementing the EGs and LFOs.

Currently the LinuxSampler SFZ Implementation document is more of a wish list of opcodes to be implemented and source for figuring out what each opcode is supposed to do. It will hopefully soon start to reflect the reality once more work have been done on the engine. Just because the SFZ reader at the moment manage to parse a definition file and recognize an opcode doesn't necessarily mean the opcode has yet been implemented in the SFZ engine.

Yes, i'm aware of the current state. I'm thinking here if we have a list of current opcodes, users not aware of the current state will know where they stand, and what will and won't work. No one is deriding the excellent work going on, or implying there's a problem.

I've been asked this question 3 times in 2 days, and as more people come on board, as there seems to be, it would possibly forestall any repetition, or perception that there's something.....wrong, when there clearly isn't, at least to us.

Alex.

I haven't yet had time to play around with the new engine(s) and look into the work that's been done in depth. But I would wager a guess, that for the time being, the following opcodes can be considered implemented by the engine:

sample=
lokey=
hikey=
key=
lovel=
hivel=

dahnielson wrote:I haven't yet had time to play around with the new engine(s) and look into the work that's been done in depth. But I would wager a guess, that for the time being, the following opcodes can be considered implemented by the engine:

sample=
lokey=
hikey=
key=
lovel=
hivel=

That would explain a lot

I will abandon work on this for now till it matures a bit. At least I learned a lot

dahnielson wrote:I haven't yet had time to play around with the new engine(s) and look into the work that's been done in depth. But I would wager a guess, that for the time being, the following opcodes can be considered implemented by the engine:

sample=
lokey=
hikey=
key=
lovel=
hivel=

There's a lot more than that implemented in the current engine. This is what I found after a quick look at the code (some of these may be only partial implemented, not sure):

• lochan
  hichan
  key
  lokey
  hikey
  lovel
  hivel
  lobend
  hibend
  lochanaft
  hichanaft
  sw_lokey
  sw_hikey
  sw_last
  sw_down
  sw_up
  sw_previous
  trigger
  loccN
  hiccN
  
  sample
  
  loop_mode
  loop_start
  loop_end
  count
  group
  
  pitch_keytrack
  pitch_keycenter
  tune
  pan
  
  ampeg_start
  ampeg_attack
  ampeg_hold
  ampeg_decay
  ampeg_sustain
  ampeg_release
  
  fileg_start
  fileg_attack
  fileg_decay
  fileg_sustain
  fileg_release
  
  pitcheg_attack

Andreas wrote:

dahnielson wrote:I haven't yet had time to play around with the new engine(s) and look into the work that's been done in depth. But I would wager a guess, that for the time being, the following opcodes can be considered implemented by the engine:

sample=
lokey=
hikey=
key=
lovel=
hivel=

There's a lot more than that implemented in the current engine. This is what I found after a quick look at the code (some of these may be only partial implemented, not sure):

• lochan
  hichan
  key
  lokey
  hikey
  lovel
  hivel
  lobend
  hibend
  lochanaft
  hichanaft
  sw_lokey
  sw_hikey
  sw_last
  sw_down
  sw_up
  sw_previous
  trigger
  loccN
  hiccN
  
  sample
  
  loop_mode
  loop_start
  loop_end
  count
  group
  
  pitch_keytrack
  pitch_keycenter
  tune
  pan
  
  ampeg_start
  ampeg_attack
  ampeg_hold
  ampeg_decay
  ampeg_sustain
  ampeg_release
  
  fileg_start
  fileg_attack
  fileg_decay
  fileg_sustain
  fileg_release
  
  pitcheg_attack

To prove it some debug statements telling you what sample is fired would really help.

Hi, I report that also the following opcodes seems to work :
seq_position=
seq_length=
lorand=
hirand=

I'm planning to convert all my Battery3 library in SFZ, so I'll be extremely happy if you'll implement the "offset" opcode.

thanks and keep up good work