Re: [Lmuse-developer] automation issues

[Robert J. <spa...@gm...>]

Hi folks,


2009/5/31 Tim <ter...@ro...>

> Hello Dan, Robert, lists. If I may offer my perspective:
>
> On May 29, 2009 06:47:18 pm Robert Jonsson wrote:
> > Hi Tim,
> > Seems there are some issues with automation in the latest and greatest.
> > Both for audio and midi.
> > For midi, please see my response to Dan's question on the user list.
> Please remember, midi automation using the mixer (touch, write etc)
>  never worked yet (that's why I didn't make the buttons red).
> I have not had time to fix it. I am planning to activate it, but not for
>  release 1.0
> Instead, midi automation is accomplished with controller graphs in the
>  midi/drum editor windows. Muse will of course also accept recorded midi
>  controller events, and they should show up in the controller graphs.
> Or you can always use the event list editor.
> Other than that, the midi automation system SHOULD be fully workable !
> Remember that Muse instruments play a big role here - use them to make
>  various midi controllers show up in the graph's list of controllers.



I was a bit lazy just referring to a mail conversation, sorry.
The problems occur while editing in the part editor. I don't automate midi
that often so I may be barking up several wrong trees but the thing that
makes me feel that it is wrong is that it works for Velocity but no other
controller. For all other controllers the bottom pane in the part editor is
just grey.



> For audio I'll try to explain.
> Simplest way to provoke it is to create one wave track. import a wave
file,
> select Touch, set the volume level at pos 0. Forward a bit, set another
> volume, forward some more and set a third volume.
> Now save the file and reload it.
> This time around it seems one of two things happen.
> Either the first automation point is skipped or the first point is the
only
> one that seems correct.

> You've got the basics: Add audio automation events by 'touching' the
> control
>  at various time positions, or by right-clicking the control and selecting
>  'add event'.
> There should be NO issues with storing and loading what you have touched -
>  "what you touched is what you get".
> Remember that muse will interpolate (smooth out) between touched points.
> The 'write' automation mode is more complicated. It is usually used when
>  the transport is running so muse will record your control motions.
>
> In lieu of an audio automation  HOWTO, I direct you to this:
> http://www.soundonsound.com/sos/Feb02/articles/pronotes0202.asp
>
> See the section titled:
> "Mixing FAQs"
> In particular the paragraph titled:
> "What's the bare minimum I need to know to start using automation?"
>
> I modelled my changes on that paragraph, with these differences:
> Touch mode can be used when when stopped so that a single value
>  can be stored. Write mode can be used when stopped so that a
>  'first value' can be queued for when you roll the transport and then
>  move the given control. It will not store until you move the control
>  while rolling.
> Of course, muse has no 'auto latch' mode.


Good write up.

I think I just found the root cause why it was not working for me. I'm
running a localized (swedish) desktop since a few weeks and one of the
quirks of swedish localization is that . is ,   e.g: 1.0302   is 1,0302
The reason I thought to test this was that there was a similar bug a long
long time ago where this definitely was the problem.

I found the fix message from the changelog:
      * changed all float printf("%f") to equivalent qt-string
        routines; dont localize decimal point so that the
        strings can be properly parsed; this should fix some
        save/restore problems in localized MusE versions (ws

I just diffed two test files where I added three automation points one with
localized muse and one without. Diffing the files reveals this difference:
<         705600 0.0166629,         1058400 1.02164,
---
>         0 1.02164,         705600 0.0166629,         1058400 1.02164,

For some reason the first value is never written to the file when MusE is
localized... this appears to be a somewhat harder nut to crack...
There's always the workaround of not running MusE localized.



> > Oh, that's right there's a third issue I found. If I use the slider menu
> to
> > go to the "next event" and the next event is long way away (or possibly
> > just the last event) it happens often that muse is kicked by jack
> (atleast
> > when jack has small buffers). Is the search for the automation point
> > somehow performed in the audio thread?
> Jack does that sometimes. Sometimes Jack will kick us out,
>  and if we allow Muse to restart Jack, no problem - it restarts.
> But other times Jack keeps on kicking us out again and again
>  until Muse can't restart the audio any more.
> I urge you to try again, restart Jack if you have to.
> Eventually you should arrive at a stable setup.


Right. This is not such a big issue since it happens during editing that
probably isn't realtime critical. The thing is though that if the Linux
version is properly realtime tweaked MusE should never be kicked out unless
there is a realtime problem in MusE, hence my question if the search is done
in the audio thread?
If MusE somehow blocks the audio thread it isn't behaving properly.
But as it works sometimes I think we might write it off as a realtime
problem with Linux, atleast for the moment.


I tried tonight and you are right: When it's bad, it is bad -
>  kicking us out a lot. But then I tried again, with the same file,
>  and it was stable.
> In general, manual motion of the cursor will tend to cause it more.
> Also, if the 'Song type' is other than 'NO', then seeking the
>  cursor to the beginning of the song causes an intense
>  process of controller initialization, which can sometimes kill Jack.
>
> > I'm having some issues with crackling also but I'm blaming my hardware
> for
> > that. I've had these problems on and off for a long time and finally
> > ordered some new hardware (upgrade time anyway) to try to eliminate it.
> Hold on - There is a certain 'type' of Jack 'crackling' which is a classic
>  symptom which affects many apps including Muse. It's NOT the hardware !
> Unless your hardware is really crappy, or you are pushing the buffer
>  size too small, or you don't have Jack 'really' running in realtime,
>  then it just might be the same problem that I'm thinking of:
> *** If you hear crackling, try Muse's 'restart audio', but note that
>  it actually never gets rid of the crackling by itself - do this too:
>  Keep hitting 'Save' until the crackling suddenly stops.
> *** I highly recommend this ***
> Muse's 'Save' is an operation which is intense, and often actually
>  CAUSES the crackling to suddenly happen (or Jack to quit).
> But repeated 'Save's can often also suddenly STOP the crackling !
>
> I have found that 'Restart audio' NEVER STOPS the crackling,
>  just 'kicks it' into another 'phase', so that 'Save' has a better chance
>  of stopping it.
> Trust me on this !
>
> Jack shutdown and static noise often appear together.



I think I know the error you are referring to. As I recall I have had
similar issues, as I recall many times with sb live /audigy cards.
Might have happened with my Delta 44 also... I think these problems are very
low level, down in Alsa.
They are not the problem I'm having now.

I'm having a dual core problem that supposedly should have been worked
around several years ago but for some reason still affect me... or if there
is some other hardware error... I try to trace it but tend to get lost and
think there are artifacts everywhere.

Basically, Athlon X2 processors, the first version, were not clock synced
between the cores, this leads to all kinds of wierd stuff, in my case,
strange artifacts in the audio stream.
Now, I ran for a long time with one core disabled and I THINK that the
problem was vanquished then (which is really the reason why I believe the
problem to be dual cores). I reinstalled some weeks ago and have tried
different things after that to be certain that all works as intended...
When using 2 cores there are definitely problems.
I tried forcing all audio processes to one core with 'taskset', this might
have worked but I'm not sure... and I tried disabling one core with
echo 0 >> /sys/devices/system/cpu/cpu1/online
This also might have worked... not entirely sure.
Along the way I finally realized that with one core my system feels somewhat
underpowered so I gave in and ordered a new motherboard, cpu and more
memory.
If it fixes the audio problem great, if not, I still got more horse power
and will have to find the cause for the issues elsewhere.

Keep it up,
Robert



>
>
> Well that's all I can stay awake to write for now..
> COMMENTS ENCOURAGED !
>
> Thanks. Tim.
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Lmuse-developer mailing list
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>