I am running 11e. When I download 11f and try to run it a message appears saying "MA3 Beta Test 10 has expired" !!

Or you just turn back your date/clock on your computer...

Which may then mess up other installed programs....

:confused:

** two lines ** I personally prefer that doing something in the "Music Playlist" panel should not change anything in the "Program Settings" panel. But at least, "Play" and "Stop" should be consistent.

OK, then logically, Stopping the music (in the Music Playlist panel) should turn off the music (i.e., uncheck the Music box in the Program Settings panel).

Same behavior in 11e, by the way.

JohnWho, Jim's comment seems to confirm that turning on the music is "intended behavior". Perhaps it depends on how many things are in the playlist, or whether there's some particular filetype (like .sgt), or what length the paths are, or whatever. I think it's unlikely to be something that depends on the version of Windows. I just don't have the time or inclination to test every possible combination.

Re: Pressing Stop should turn off the Music in the Settings Panel -

Fair enough. I have changed the code thus:

If Music was already on when you brought up the Playlist panel, then it will still be on when you exit the panel, no matter what you have done with the Play or Stop buttons.
If Music was off when you entered the Playlist panel, pressing Play will turn Music on until you hit Stop. If you don't hit Stop, Music will be on until you turn it off in Program Settings or hit "M".

** 2 Lines ** Please fix any other strange or inconsistent behaviors, too.

Strange behaviors include:

If music is "on" in Program settings, opening the Music Playlist screen stops the music that was playing for the "Settings" panel. You only get the music to play (while on the playlist screen) if you click on "Play".

With a blank playlist, clicking on "Play" plays music. (Of course, that may not be inconsistent, I guess).

The current behavior is necessary. DirectMusic is a complex and finicky beast to control. I had all kinds of problems with it (crashes, page faults, etc.) until I added code which stopped the current music whenever the Playlist panel was brought up.

Busy getting 11g out...

Understood. I still prefer the "other" behavior for Play/Stop, [Alternatively, please put a visible note on the Music panel that explains the side effects (plural) of the two buttons]

And yes, I do recognize that there would be some more programming work involved in saving the "before" status of Play, and restoring it later. It's much less programming to just make "Stop" turn off the program setting.

Clearly your call, of course.

Makes sense to me and sounds like something we'll be able to test in 11g.

I'll reflect this in the Readme file, once I try it, so I can explain it in the appropriate place(s).

OK. I still request that there be some information about this, displayed in the "Music Playlist" panel.

OK, after a bit more thought, I'd prefer that the "play" and "stop" in the Music Playlist screen only affect the user while in that screen and not have any effect on the general Program Settings one way or the other.

In my opinion, this would be more consistent with this phrase which I believe is correct for all settings screens:

"Changes you make on this screen will only take effect when you click on the "OK" button. Clicking "Cancel" will not save your changes and all settings will remain as they were."

(Quote from Preliminary Proposed MA3.1 Draft Readme.txt) :)

That is how Cancel already works. I runs the ReadRegistry() routine, which replaces everything with the last saved value.

By the way - the holdup on 11g is the Limit Frame Rate feature. I was hoping to get it working for this release, but haven't come up with an algorithm that works. It keeps hunting for the proper frame rate. In my flying days, we called it a PIO - Pilot-Induced Oscillation. By correcting for a variation which happened a second ago, your corrections build up until you overshoot the proper pitch angle, so you correct for that, and so on until the oscillations get really wild. I may have to shut the feature off for this release.

Is the new "Limit Frame Rate" feature necessary or just one of those "nice to have new" features?

Maybe it can wait until MA 3.11?

Just wondering out loud.

It will definitely be in 3.1, just probably not working very well in v11g.

Overcorrection resulting in Oscillation is a real problem in the process industry. Oil refineries, dairies, paper plants, etc. My dad worked in this industry for 50 years and was one of the pioneers in how these facilities are controlled and laid out. Process control uses a PID to keep things from getting out of hand.

But in your situation, what I would do is when you are going to have a reaction, multiply by .8 before applying it. This way you will never overreact. Instead, you'll see a target and creep up on it, rather than the chance of overshooting it.

The problem with that is the Sleep command can't use decimals, only whole numbers.

Suppose, when the "Limit Frame Rate" option is selected and once the program starts, and once the 2 ossilating "Sleep" numbers are determined, you then have the program "select" one of them, which would immediately stop the ossilation?

Just a thought.

I was leaning the other way - oscillating more often for a smoother average FPS.

Which would provide a lower CPU usage?

It would be a proportional amount for whatever FPS you set, switching rapidly between the two CPU usage amounts.