On fre, 2004-11-05 at 22:48, Paul Davis wrote: Wait a second while I google for sooperlooper ... ... ... Mmmm ... It looks to me like you haven't got a massive amount of parameters (like ie the DX7?) I never had a problem with parameter changes coming in at the midi port. Problem is that I have no sysex ID [1] (And yes, I did notice that there is an implementation of DX7 for dssi. It relies on sysex for individual parameters.) 32 something programmable knobs (with multiple destinations) on a usb/midi surface is probably more than you'll ever have time to understand (nor me), but when it comes to setting up the whole sheebang, we'll both want to have access to *all* parameters. This is where the native UI has its place. You'll do the setup off-line, therefore races are a minor concern. *1) Yamaha is a registered midi vendor, and have their own sysex preample. We have not! mvh // Jens M Andreasen

On lör, 2004-11-06 at 03:53, Paul Davis wrote: ... I was not aware of a research range. Which IDs are open? /j

On Fri, Nov 05, 2004 at 08:40:42PM +0100, Jens M Andreasen wrote: The midi is sent to the plugin via DSSIs version of the run() callback. The UI OSC stuff is intended for sending test notes and things of that kind, though can use it for more if you really want to. The UI MIDI -> plugin comms channel could be made realtimeable is we required that host support OSC bundles, but currently we dont. - Steve

On Sat, Nov 06, 2004 at 08:55:18 +0100, Jens M Andreasen wrote: run_synth*() are the ones that supports MIDI, they take a snd_seq_event_t * parameter which are ALSA seq structs timestamped against the current audio buffer. The interface is explained in dssi.h, around line 223: /** * run_synth() * * This member is a function pointer that runs a synth for a * block. This is identical in function to the LADSPA run() * function, except that it also supplies events to the synth. * * A plugin may provide this function, run_multiple_synths() (see * below), both, or neither (if it is not in fact a synth). A * plugin that does not provide this function must set this member * to NULL. Authors of synth plugins are encouraged to provide * this function if at all possible. * * The Events pointer points to a block of EventCount ALSA * sequencer events, which is used to communicate MIDI and related * events to the synth. Each event is timestamped relative to the * start of the block, (mis)using the ALSA "tick time" field as a * frame count. The host is responsible for ensuring that events * with differing timestamps are already ordered by time. * * See also the notes on activation, port connection etc in * ladpsa.h, in the context of the LADSPA run() function. * * Note Events * ~~~~~~~~~~~ * There are two minor requirements aimed at making the plugin * writer's life as simple as possible: * * 1. A host must never send events of type SND_SEQ_EVENT_NOTE. * Notes should always be sent as separate SND_SEQ_EVENT_NOTE_ON * and NOTE_OFF events. A plugin should discard any one-point * NOTE events it sees. * * 2. A host must not attempt to switch notes off by sending * zero-velocity NOTE_ON events. It should always send true * NOTE_OFFs. It is the host's responsibility to remap events in * cases where an external MIDI source has sent it zero-velocity * NOTE_ONs. * * Bank and Program Events * ~~~~~~~~~~~~~~~~~~~~~~~ * Hosts must map MIDI Bank Select MSB and LSB (0 and 32) * controllers and MIDI Program Change events onto the banks and * programs specified by the plugin, using the DSSI select_program * call. No host should ever deliver a program change or bank * select controller to a plugin via run_synth. */ void (*run_synth)(LADSPA_Handle Instance, unsigned long SampleCount, snd_seq_event_t *Events, unsigned long EventCount); - Steve

On Sat, 06 Nov 2004 12:25:45 +0100 Jens M Andreasen <jens.andreasen(a)chello.se> wrote: Even if the events come from a midi device you want to avoid jitter. Imagine a periodsize of 48000 frames. You don't want your midi events all take effect at period boundaries, but at the appropriate time inside the period.