Print

[TraumFlug]

I've just compiled mt 0.90.85 on an ubuntu 9.10 system with self-compiled jack 1.9.5, and finally...jack works!!

it's working really well, I've just tested at 88200 khz rate, and milky seems to be able to handle that, no aliasing on high-pitched notes that _did_ alias badly at 48000 with the cheapest resampler! strange that sdl/alsa drivers don't offer >48000 in the gui while it's working with jack, maybe that should be fixed?

well...the problem: sometimes with jack in rt mode (happened at 48khz, so I doubt it's related to an unsupported sample rate), when I click around the system and reenter the mt window, the player becomes unresponsive to input! gui updates well, sound is gap/xrun-free, with cpu around max (it's a slow pc), but keyboard and mouse input won't respond for long times, like it takes half a minute after I clicked something (also the wm close button) for mt to respond, keyboard also lags like that. working is impossible when it happens (other than listening to the song & watching the gui).

I'd really like to get that fixed, because it's annoying. anyone got ideas on how to solve this prob?

btw, how does milky do its mixing & passing data to jack? jack works with 32bit floats, I hope the mixing isn't 16bit integer & then converting to floats (but I fear so...)

[Deltafire]

The mixer output is 16-bit, which is simply converted to a float for the JACK driver.  Feel free to improve on this if you wish

Not sure why the player is unresponsive to input - perhaps there is just not enough CPU time to process the input events at high sample rates?

[TraumFlug]

o.k., thing is it seems my cpu is to slow...old 1ghz machine  

I've tried with alsa driver now, too, and can reproduce it happily by choosing fast sinc interpolation, unlike with the jack driver, I also get sound dropouts then...have to kill mt to get rid of it, interface just doesn't respond, but gui & sound stutter on ad infinitum...

I mean it's ok that the sound/gui get choppy when no cpu ressources are available, but I think at least input handling should get some higher priority somewhere, so one can at least stop the stuttering  

but maybe it's a problem with the sdl input handler? I think I remember it can't be threaded? well, I'll try to look at the sources someday when I feel whacky...

p.s.: I found that the main ressourcekiller seems to be the graphics, mainly the scrolling tracks. i.e. 1024x768 = +/- 100% cpu usage, 800x600 = +/- 50% , with same resampling/frequency!

p.p.s.: well, I happen to like using spd = 3 and bpm's above 150. I've tried to set spd to 6 on one of my songs (making it play at half speed :p), and the cpu usage went straight down. It seems like the gui updates the trax based on the trackspeed, and doesn't skip any frames properly!
the rate is no prob., I can playback/edit at 96khz rate fine (yeah dope sound!), as long as the gui doesn't hog ressources too much...so the mt mixer is quite fine...it's the gui where the problem is, and I think some input event list just piles up totally when cpu max is reached. duh, maybe my post should've be placed at the "support" channel first. my apologies.

[Saga Musix]

o.k., thing is it seems my cpu is to slow...old 1ghz machine

Whoa. MilkyTracker is a FT2 clone, and FT2 ran perfectly on machines with less than 100 MHz.

It seems like the gui updates the trax based on the trackspeed

Yeah, why should it be done any different?

I would assume that you probably are missing proper drivers for your graphics card, that's often a reason for sluggish GUI updates.

[Deltafire]

There are some command line switches for the SDL version (documented in readme_unix I think).  The one you might like to try is:

./milkytracker -bpp 16

..which will configure Milkytracker to use a 16-bit screen resolution.  You could also try the values 24 and 32 (I can't remember which one MT defaults to).

[pailes]

Whoa. MilkyTracker is a FT2 clone, and FT2 ran perfectly on machines with less than 100 MHz.

You can't compare MilkyTracker to FT2. FT2 ran in a single threaded environment with direct access to both sound and graphics hardware.
In modern operating systems there are a dozen layers of indirection plus the MilkyTracker GUI is purely software-rendered in true R/G/B colorspace. While 1ghz seems very much in comparison to a old DOS box it's really not much when you want to draw a 1024x768 GUI in software.

[Deltafire]

This is probably the same issue as this, which has now been fixed.