Re: [seq24-users] about 0.7.0

[Florian S. <mis...@gm...>]

On Fri, 26 Aug 2005 10:51:57 +0200
Olivier Doar=E9 <no...@fr...> wrote:

> May i give you some small enhancements that would greatly improve my work=
flow
> with this tool? (maybe other users too)... ok let's go:
>=20
> - I often connect it with multiple soft synths. When reloading a session =
file,
> if the order of the synths has changed, i must reconfigure by hand each l=
oop...
> until next reloading... I don't know if it is the best idea but saving
> connections by port name instead of port number would probably work bette=
r.

I second this though i think the best would probably be a combination of
those: Save both alsa seq client and port id and also the port name.
When starting up, do somethign like this:

1] check whether we find any exact matches for client/port/portname and
connect these.=20

2a] on the remaining tracks (which have not been "resolved" during stage
1]), check for name matches only and connect those..

2b] like 2a, but use client/port id instead.

or something similar. you get my drift. Whether to use 2a or 2b would
depend on a user setting..

I also have another feature request for Rob:

It would be cool to be able to select the RT prio of seq24 when running
in priority mode. Here's my reasoning:

Imagine you use softsynths with jackd running at RT prio 70 and a rather
huge periodsize. Also imagine the softsynth takes a rather huge part of
the period time to actually produce its output. Let's say half the
period time. Now for this time seq24 will not get scheduled which will
introduce jitter.

As a midi sequencer is very leightweight (or at least it should be ;))
it makes much sense to give it a priority higher than i.e. jackd and all
its clients. I hacked the source and set the sched_priority to 80 and it
works just fine (jackd runs a t prio 70 here as i run a RP kernel and
all non soundcard/rtc irq handler threads run around prio 50).
Softsynths who give their midi receiption and timestamping thread a
higher prio then its jack audio thread will thus experience less jitter
when driven by the modified seq24.

Does that make sense? :)

Regards,
Flo

Besides that: Big ups to yuo rob, for giving us this awesome software!

--=20
Palimm Palimm!=20
http://tapas.affenbande.org