On Thursday 07 October 2010, James Le Cuirot wrote: > > Hmm, because they are private, that means that we are free to change > > the implementation (and even remove the field) between FS versions. > > I'm not sure I want to give up that freedom right away, what does the > > rest of the list think here? > > > > Also, I'm not exactly seeing why wrapping this in another struct > > would be "a PITA", but you can also malloc another array next to the > > event array containing the times if that works better for you. That > > would also stop the overwriting problem you have. > > I'm being very conservative with my memory management and backing out > of a failed malloc could get messy with nested structs. Having a > separate array works fine though. Should have thought of that! I've now > made that change.
I don't know if you have already seen two examples using the sequencer (fluidsynth_metronome.c and fluidsynth_arpeggio.c) in the doc/ directory. One idea behind them is to keep the events, notes, patterns, the song, in whatever structure that comfortably represents (for your program) the list of timestamped events: the music, and then use new_fluid_event() and delete_fluid_event() just for the moment when you need to schedule the events to the sequencer. > > I think you'll have to look at fluid_player_set_midi_tempo and do > > something similar, as you're doing your own midi file parser, that > > is, combine PPQN with the MIDI_SET_TEMPO meta event. > > I read up some more on SYSEX and found out what these meta events are. SysEx is a real-time MIDI event (that may exists in a MIDI events stream, for instance in a wire connecting two MIDI devices) and Tempo is a SMF meta-event, that only exists inside MIDI files. There are also text and other types of meta events in SMF http://home.roadrunner.com/~jgglatt/tech/midifile.htm http://home.roadrunner.com/~jgglatt/tech/midispec/sysex.htm The synth object doesn't do anything currently with sysex events, or with SMF meta-events. > I now understand that the PPQN alone isn't enough even for the initial > tempo so I need to handle this event. The problem is, as I mentioned > before, there isn't a fluid_event function for tempo changes. I tried > to work around this by dealing with it in a client callback but when I > call fluid_sequencer_set_time_scale inside the callback, the game > crashes with this horrific error. This looks like a sensible design, scheduling a timer event (using the functions fluid_event_timer() and fluid_event_set_dest() with a client destination handler) for each tempo change in the MIDI file. Each timer event shall trigger the client callback, which in turn should call to the fluid_sequencer_set_time_scale() function corresponding to the new tempo. If this call crashes, there is a bug somewhere and we need to investigate. It would be nice (and easier) to have also a META sequencer event type to deal with these issues. Regards, Pedro _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev