opensource sample lib format
Re: opensource sample lib format
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.
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.
- dahnielson
- Moderator
- Posts: 632
- Joined: Wed Jan 23, 2008 11:25 pm
- Location: Linköping / Tranås, Sweden
- Contact:
Re: opensource sample lib format
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.
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.
Anders Dahnielson
Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux
Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux
Re: opensource sample lib format
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.
- dahnielson
- Moderator
- Posts: 632
- Joined: Wed Jan 23, 2008 11:25 pm
- Location: Linköping / Tranås, Sweden
- Contact:
Re: opensource sample lib format
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=
sample=
lokey=
hikey=
key=
lovel=
hivel=
Anders Dahnielson
Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux
Ardour2, Qtractor, Linuxsampler, M-AUDIO Delta 1010, Axiom 61, Korg D12, AKAI S2000, E-MU Proteus 2k, Roland R-5, Roland HP 1300e, Zoom RFX-1000, 4GB RAM x86_64 Intel Pentium Dual 1.80GHz Gentoo Linux
Re: opensource sample lib format
That would explain a lotdahnielson 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=
I will abandon work on this for now till it matures a bit. At least I learned a lot
Re: opensource sample lib format
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):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=
- 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
Re: opensource sample lib format
To prove it some debug statements telling you what sample is fired would really help.Andreas wrote: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):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=
- 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
Re: opensource sample lib format
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
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