[yoshimi] Re: Eating your own dog food...

  • From: Chris Ahlstrom <ahlstromcj@xxxxxxxxx>
  • To: yoshimi@xxxxxxxxxxxxx
  • Date: Wed, 30 Dec 2015 10:50:05 -0500

I recommend running it under Valgrind. The main hassle with valgrind
is that it also shows the memory issues in code that isn't yours (e.g.
X Windowing).

Yeah, I've saved all your missives for when I get arsed to update
yoshimi-doc. It'll be a pretty big job by the time I get around
to it.

I'm close to getting the event editor to work in Sequencer64 (major
fork of seq24.)

Chris

-------- Will Godfrey 13:44 Wed 30 Dec --------

On Mon, 28 Dec 2015 18:19:00 -0500
Chris Ahlstrom <ahlstromcj@xxxxxxxxx> wrote:

Sounds like you built yourself a good test song!
:-)

Humpf!

Sometimes I think Yoshimi is playing games with me.

Today I did run after run with just 1 (inaudible) Xrun. However, I'm getting
more convinced that this is a memory allocation problem, as I was later able to
produce a lot of them. The sequence of events was as follows.

I started Qjackctl, then Yoshimi, then Rosegarden.
I loaded the problem file into Rosegarden and ran it repeatedly - no Xruns.

With Rosegarden still in place I ran aplaymidi with a midi version of the same
file. In the third run I got my one measly Xrun.

I made a cup of tea - probably highly significant (ask Arthur Dent) :)

I then closed Rosegarden and hit the reset button on Yoshimi.
Next time I ran aplaymidi there were lots of Xruns, the worst of which occurred
when loading patches with a PadSynth component.
Immediately running aplaymidi again produced just 1 Xrun, and the run after than
none at all.

So, here is what I'm guessing.

On the first run the memory map is well ordered. Rosegarden is sitting 'above'
Yoshimi (which will have a full set of default parts). As each part gains a new
patch, memory will be allocated above Rosegarden, as the existing part space
will be too small. Later overwrites of parts will again move up if the new one
is too big for the current space.

Removing Rosegarden then clearing down Yoshimi probably returns parts to the
original space, but now there is a highly fragmented area sitting above it where
Rosegarden was, so when larger blocks are called for, the system has to scramble
to garbage collect.

PadSynth patches require a sizeable block of continuous memory, which would
explain their greater susceptibility.

I could of course be quite wrong :)

If anyone wants to play with this themselves I've attached the midi file. There
are only a few requirements.

In MIDI settings Root Change must be 0, and Bank Change LSB. Program change must
be enabled, as must Enable Part On program Change.

Root Path ID 9 should point to the default set that comes with Yoshimi, and to
get the drum track it needs to be from the latest master. 'Moor Drums' was
never generally available before.

Oh, talking of dogfood, there have been quite a few docs updates Chris :D
Most significantly, Command_Line.txt now actually tries to explain how to use
this instead of just giving a list of (now changed) commands!

--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.



--
You had some happiness once, but your parents moved away, and you had to
leave it behind.
Yoshimi source code is available from either:
http://sourceforge.net/projects/yoshimi
Or: https://github.com/Yoshimi/yoshimi
Our list archive is at: https://www.freelists.org/archive/yoshimi
To post, email to yoshimi@xxxxxxxxxxxxx

Other related posts: