Re: [yoshimi-user] back in the game
- From: "Jonathan E. Brickman" <jeb@xxxxxxxxxxxxxxx>
- To: cal <cal@xxxxxxxxxxxx>, yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Sat, 22 May 2010 12:38:33 -0500
Not quite redundant, still highly desirable. The compromise I've aimed for is to
ensure that silence is all that reaches the audio output while patch changes etc
are in progress. But that still leaves the inherent limitations of just when
those
changes can take effect, and in particular how long they take to become
effective.
I think compromising workarounds are the order of the day for now.
cheers, Cal
Cal, it is great to have you back. I'm glad you are pondering what it
is best for you to do in general, rather than pounding anything for any
other reasons; I have walked that road enough to bar the way for myself!!!
I would appreciate, in that light, if you would store the below away
until you feel like looking at it :-)
Looking at the above, what comes to me is the following. It is probably
a much simpler derivative of something we pondered a while ago.
1. The problem at hand, seemingly, is patch-changes and behavior during
them.
2. If I understand things as they are now, we have exactly one (1)
thread doing output using that ring buffer thingy you explained to me,
which connects exactly once to Jack.
3. It seems to be a standard practice, and a standard problem, to do #2
as is, across all audio, perhaps even Windows with ASIO.
4. Let's ponder this. Instead of one thread and one ring buffer and
one Jack API connection, let's have two. At startup, jacklink[0] (I'm
making up object names now, I probably shouldn't) is running and hot,
and jacklink[1] is connected, active as far as jackd is concerned, but
not dedicated to delivery of the current patch. If it is a must (it
would depend on Jack architecture and real-world behavior I guess), the
cold jacklink object could deliver silence when it is cold. Jackd
itself would maintain the mixing of the hot and cold datastreams. This
might end up being the most reliable of all. And it allows a beautiful
blending-transition between two patches. And no munging of the synth
code is required, and no latency added :-)
5. During patch-change, jacklink[0] becomes "cold", and jacklink[1]
becomes "hot". But there's no jolting of audio hardware, no
interruption of APIs et cetera, because both jacklink objects stick
around, both Jack API connections still remain throughout.
6. The jacklink objects could come across to the Jack patchbay as
either discrete connection objects, or alternatively, each jacklink
object could constitute two output channels within the one current
patchbay connection. I'm thinking the latter would be less
resource-intensive, but I have no idea which would be easier to set up,
either on the Yoshimi side or in the patchbay itself.
7. After all the above works, we have the groundwork for a larger
improvement. Yoshimi is multitimbral, i.e., it is capable of delivering
several of its tones at once. Each of these could have its own jacklink
object. The result is offloading much of the work from Yoshimi, onto
jackd, where I am thinking it may be much more efficient. Especially in
a Jack2 environment.
I am attaching my .src.rpm and rpms. I have tried to get input from
Fedora and CCRMA folks as to how to submit it, but have not received
input yet. They'll probably be stripped off the email to the list; if
anyone wants one, please do email me direct :-)
J.E.B.
--
When we were married, Lori and I were reminded
that men like to be "dragonslayers".
Today we had a laugh: a man's wife had better tell him
about her pet dragon!
Attachment:
yoshimi-0.056-1.fc12.src.rpm
Description: application/rpm
Attachment:
yoshimi-0.056-1.fc12.i386.rpm
Description: application/rpm
Attachment:
yoshimi-0.056-1.fc12.x86_64.rpm
Description: application/rpm
Attachment:
yoshimi-debuginfo-0.056-1.fc12.x86_64.rpm
Description: application/rpm
Other related posts: