As a simpler change that might be less controversial, how about just
extending the sequencer API to make it easy to do these things without
needing to resort to a lower level API? Then as Brett suggested, OSC
could be implemented on top through its own library. This would mean,
for example, creat
I didn't come here to argue. I'm suggesting ways to make FluidSynth a
better program. If you don't want my help or ideas, just say so and
I'll go away.
Peter
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/flu
> You guys are wasting your time. Fluidsynth is a library, load it into
> Python via ctypes, and roll your own OSC interface on top.
Does it actually support all the features needed to do that? I
haven't studied the code in detail, but what I've seen from looking at
the API doesn't appear to. F
> Your argument is based on a random Wiki page, containing a proposal that has
> been adopted by just one single project.
I don't know where you're getting your information from, but you are
completely wrong. The SYN namespace is generally recognized as the
standard mechanism for controlling synt
> OSC doesn't define one set of messages with standard semantics
Not true: that's what the SYN namespace is for. See
https://github.com/fabb/SynOSCopy/wiki. OSC and MIDI approached this
from opposite directions. MIDI began with a standard set of commands,
then added a mechanism for vendor speci
Have you thought about adding OSC support? MIDI is very limiting as a
control mechanism. Being able to use OSC would make FluidSynth a lot
more useful and powerful.
Peter
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman
