I've confirmed that Kyle Super's code for using SoundFonts in ChucK is working with version 1.2.1.2 in OS X, and it is said to work in Linux as well. These are the steps I took to install: 1) Download and install FluidSynth from http://fluidsynth.resonance.org/trac/wiki/Download. I installed version 1.0.8 from source with "./configure && make && sudo make install" 2) Apply the attached diff to chuck 1.2.1.2. 3) Compile ChucK with "make osx". If on Linux, build with "make alsa". -- Tom Lieber http://AllTom.com/
SoundFonts part II: using SoundFonts. --- SFont f => dac; int chan; float key; float veloc; 0.07 => f.norm; // easy to find using the Internet "Gort's-DoubleDecker_J1.SF2" => f.read; while( true ) { Std.rand2( 0, 15 ) => chan; Std.rand2f( 50.0, 300.0 ) => key; Std.rand2f( 0.0, 127.0 ) => veloc; chan => f.channel; key => f.freq; f.noteOn( veloc ); 1::second => now; f.noteOff( veloc ); } --- -- Tom Lieber http://AllTom.com/
SoundFonts part III: ALSA's Revenge The makefile.alsa included in the original diff was for an old version of ChucK. The attached, complete diff is more likely not to take you back through history, though I still have no Linux to test that it works. Someone, please do. :) -- Tom Lieber http://AllTom.com/
Hi Tom
The sf patch works on linux but are some loose lines
in the makefile.alsa when apply the patch (patch < sfont_1.2.1.2.diff).
I really don't know how to make - apply a diff - patch :)
line 37?
util_hid.o uana_xform.o uana_extract.o $(SF_OBJ)
lines 202 - 206?
uana_xform.o: uana_xform.h uana_xform.cpp
$(CXX) $(FLAGS) uana_xform.cpp
uana_extract.o: uana_extract.h uana_extract.cpp
$(CXX) $(FLAGS) uana_extract.cpp
I think sf produce some particular issues.
When loading, if the time of read is so high the vm have to wait.
Is it a possible solution to load sf in a thread and send an event
when done?
The .freq method in a sf file, maybe have no precise sense, the
real frequency depend of the recorded sample and the pitch region,
maybe a simple .key method is better...
or make the calculus of sample - pitch - region - pitchbend to take the
accurate frequency... (if the sf file support that)
...maybe the nature of this UGen is simple different...
Information retrival about sf files is also needed...
I like this UGen!!!!
runs with rec.ck --silent!!!
Sorry about my English!!
Schreers! (a sporked cheers)
Lucas
2008/10/2 Tom Lieber
SoundFonts part III: ALSA's Revenge
The makefile.alsa included in the original diff was for an old version of ChucK. The attached, complete diff is more likely not to take you back through history, though I still have no Linux to test that it works. Someone, please do. :)
-- Tom Lieber http://AllTom.com/
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
lucas samaruga;
When loading, if the time of read is so high the vm have to wait. Is it a possible solution to load sf in a thread and send an event when done?
This approach has been suggested in the fileI/O design specs on the WiKi. I feel this is a very good idea that could be usefully applied in more places where ChucK's "strong timing" may conflict with the OS's timing, or limitations to the computer's capabilities. SndBuf.read() comes to mind as does the MIDI out cue and of course this is a clear example as well. Yours, Kas.
On Sat, Oct 4, 2008 at 7:48 PM, lucas samaruga
The sf patch works on linux but are some loose lines in the makefile.alsa when apply the patch (patch < sfont_1.2.1.2.diff). I really don't know how to make - apply a diff - patch :)
line 37? util_hid.o uana_xform.o uana_extract.o $(SF_OBJ)
lines 202 - 206? uana_xform.o: uana_xform.h uana_xform.cpp $(CXX) $(FLAGS) uana_xform.cpp
uana_extract.o: uana_extract.h uana_extract.cpp $(CXX) $(FLAGS) uana_extract.cpp
I don't know off-hand how to apply a patch either. I'd have to look it up. :) English diff time! 1) Add "-lfluidsynth" to LIBS 2) Add "ugen_sfont.o" to OBJS 3) Add rule for making ugen_sfont.o: ugen_sfont.o: ugen_sfont.h ugen_sfont.cpp $(CXX) $(FLAGS) ugen_sfont.cpp The other stuff that was removed (uana_xform and uana_extract) were accidental and is likely necessary.
I think sf produce some particular issues. When loading, if the time of read is so high the vm have to wait. Is it a possible solution to load sf in a thread and send an event when done?
The biggest problem with this is that it means the shred which does the load gets lost in time. It is out of sync because the load time couldn't be predicted, so you have to do extra stuff to resync it. It seems better to stay deterministic and just encourage preloading. FileIO and network delay seem like special cases where falling out of sync for the sake of the stream may be acceptable.
The .freq method in a sf file, maybe have no precise sense, the real frequency depend of the recorded sample and the pitch region, maybe a simple .key method is better... or make the calculus of sample - pitch - region - pitchbend to take the accurate frequency... (if the sf file support that) ...maybe the nature of this UGen is simple different...
I didn't develop the code, but it sounds like you're saying .freq is acting more like SndBuf's .rate and should be named something else?
Information retrival about sf files is also needed...
What do you mean by this?
I like this UGen!!!! runs with rec.ck --silent!!!
^_^ -- Tom Lieber http://AllTom.com/
Tom Lieber The biggest problem with this is that it means the shred which does
the load gets lost in time. It is out of sync because the load time couldn't be predicted, so you have to do extra stuff to resync it. It seems better to stay deterministic and just encourage preloading.
I agree that this event would come at a time that wouldn't be deterministic from ChucK's perspective but I'd prefer to have a shred that resumes running as soon as it's useful again over a shred that sends deterministically timed instructions to a soundfont that isn't yet loaded. I imagine we'd only use such a event in the case of instructions that wouldn't make sense to send before having finished loading. As I understand the situation there would be no need for extra stuff in many cases, we'd just place the sync instructions (of whatever nature) after we made sure the font was loaded instead of before. The exception would be shreds that get their start timing implicidly defined by the moment they are sporked or added. in that case; yes, some extra syncing would be needed but isn't this a case of ease of syncing v.s. ease in preventing audio glitches or missed notes? I do believe I have at least once seen the situation where reading a few large files into SndBuf's and starting to use them immediately after that seemed to cause issues (to the tune of needing a complete computer reboot). I'm not yet sure about this but if that's true then such things too could perhaps be prevented by having the shred wait until the SndBuf has finished loading. Right now I believe .chunks() is expected to deal with that there but that function doesn't take HD or memory speed into account and hence there is no way of expressing "as fast as possible but no faster" which I would like to be able to express. I hope that made sense, I'm mainly interested in the link between ChucK's timing and the computer's capabilities here; I'd like to try your work out but my soundcard doesn't support soundfonts. Yours, Kas.
On Sat, Oct 4, 2008 at 10:10 PM, Kassen
Tom Lieber
The biggest problem with this is that it means the shred which does the load gets lost in time. It is out of sync because the load time couldn't be predicted, so you have to do extra stuff to resync it. It seems better to stay deterministic and just encourage preloading.
I agree that this event would come at a time that wouldn't be deterministic from ChucK's perspective but I'd prefer to have a shred that resumes running as soon as it's useful again over a shred that sends deterministically timed instructions to a soundfont that isn't yet loaded. I imagine we'd only use such a event in the case of instructions that wouldn't make sense to send before having finished loading.
As I understand the situation there would be no need for extra stuff in many cases, we'd just place the sync instructions (of whatever nature) after we made sure the font was loaded instead of before. The exception would be shreds that get their start timing implicidly defined by the moment they are sporked or added. in that case; yes, some extra syncing would be needed but isn't this a case of ease of syncing v.s. ease in preventing audio glitches or missed notes?
I do believe I have at least once seen the situation where reading a few large files into SndBuf's and starting to use them immediately after that seemed to cause issues (to the tune of needing a complete computer reboot). I'm not yet sure about this but if that's true then such things too could perhaps be prevented by having the shred wait until the SndBuf has finished loading. Right now I believe .chunks() is expected to deal with that there but that function doesn't take HD or memory speed into account and hence there is no way of expressing "as fast as possible but no faster" which I would like to be able to express.
The crashes are bad, but I think just as bad would be the odd situations one might get themselves into when trying to use something that slips out of time like that. For example: SndBuf snd => dac; ... fun void player() { while(true) { 0 => snd.pos; snd.samples()::samp / snd.rate() => now; snd.rate() * 1.1 => snd.rate; } } ... spork ~ player(); ... "large_sound.wav" => snd.read; Swapping the last two lines would make the code run the same as you'd expect today. With them as they are, what would happen? Would the symptoms be obvious enough that it could be debugged? At least files are already thought of as one-at-a-time resources. Simpler: SndBuf snd => dac; "large_sound.wav" => snd.read; <<< snd.samples() >>>; This would become something like: SndBuf snd => dac; "large_sound.wav" => snd.read; snd.loaded() => now; <<< snd.samples() >>>; -- Tom Lieber http://AllTom.com/
Hi Tom
The .freq method in a sf file, maybe have no precise sense, the
real frequency depend of the recorded sample and the pitch region, maybe a simple .key method is better... or make the calculus of sample - pitch - region - pitchbend to take the accurate frequency... (if the sf file support that) ...maybe the nature of this UGen is simple different...
I didn't develop the code, but it sounds like you're saying .freq is acting more like SndBuf's .rate and should be named something else?
I think no (sorry for my English), That I would said that there is not a manipulated freq but a recorded sample in a particular file format, the acces an behavior are differents from the standpoint of MIDI manipulation.
Information retrival about sf files is also needed...
What do you mean by this?
Information about the bank, instruments, registers, mapping, for manipulation within chuck, maybe not a great thing.
Cheers Lucas
participants (3)
-
Kassen -
lucas samaruga -
Tom Lieber