DSP Robotics Support

STEREO AUDIO MP3 PLAYER (PICTURE ONLY):

I am still working on this project as it has the following shortcomings (all other items are functioning correctly):

1) No Fast Forward/Reverse.

2) No Skip to Skip songs.

3) No repeat.

It seems that the only way to implement Fast Forward/Reverse is to internally convert the MP3 to a *.wav file?

The interface, well, it is very plain but still practical. There are other settings that cannot be seen on the front panel since it is situated on a sliding window which slides out when a hidden switch on the front panel is activated. The speaker diaphragms do vibrate back and forth in Sync with the music.

NOTE: Long ago Martin was so kind to help me out with the AGC.

As a side issue I’m very interested in your slide-out method Tiffy.

I’ve been experimenting with the idea of sliding modules into view, but the re-draw rate is horrible, or I have to make the slide painfully slow.

I wonder what you found and if you have a better way than counting for the X or Y positions on the MGUI…

Maybe a Ruby solution?

Cheers

Spogg

Spogg wrote:As a side issue I’m very interested in your slide-out method Tiffy.

I’ve been experimenting with the idea of sliding modules into view, but the re-draw rate is horrible, or I have to make the slide painfully slow.

I wonder what you found and if you have a better way than counting for the X or Y positions on the MGUI…

Maybe a Ruby solution?

Cheers

Spogg

Hello Spogg, I have put the "slow slide-out" method aside long ago, in fact, the "slide-out" in my project actually "shoot-out" which in my opinion is more practical as it saves time when one has to make quick setting changes etc. If I mention the wording "slide-out" it is just my way of speaking. B.t.w., I noticed from the work of professional programmers who sell their software that many are doing the same as what I am doing with my version of the "slide-out".

regards

Thanks Tiffy.

So how many stages are there in your "slide"?

I found 5 is a reasonable maximum, but still not that great.

Spogg wrote:Thanks Tiffy.

So how many stages are there in your "slide"?

I found 5 is a reasonable maximum, but still not that great.

Hi Spogg, sometimes during the week or maybe next week when I have a bit more free time I will rip the "slide" from my project and upload it here.

Sliding is redrawing two images simultanously. That makes it heavy on the CPU. Therefore I wouldn't recommend sliding large sizes. You will get away with a slide of small menus etc., but not with an application sized view.

SLIDE-OUT WINDOW (SLOW):

Spogg, here is the schematic which I used previously, try it and see if it works for you.

However, it is not the other schematic I use to snap the window in and out.

The Description is inside the Schematic.

NOTE: It is true what Tulamide says if the Sliding Panel is large and have many items in it the redraw is still terrible (Quantum computers are on the horizon...but that also involves different programming software).

SLIDE-OUT WINDOW (SNAP):

This is the same schematic I use to snap-out a window in my other projects.

I do not use very large complicated schematics so I don't know if this will be of any use.

Thanks Tiffy

Your solution is similar to mine but yours is far more elegant!

I’ve improved things in mine by using a Ruby-based customisable ticker to increment the counter and it can go faster than the Tick 100 prim I was using, so I’m a lot happier now.

Cheers

Spogg

A simple tip, if I may. You both are trying it pixel-based (grid-based). In game development, it is all about moving graphics around as fast as possible, and as similar as possible. The latter means, the game should behave the same, no matter if played on a 1 GHz processor, or a 3 GHz processor. Makes sense, right?

Now, your approach with a timer moving pixel/grid-based, does not act the same on different PCs. In game development, everything is strictly time-based. It is defined that a movement from a to be takes x seconds, and depending on the PC it is run on, the step values will largely differ. To achieve that, use lerp and deltatime.

Use linear interpolation in the form of

lerp(a, b, t)

where a and b are the start and stop position and t a value between 0 and 1. 0 = a, 1 = b, 0.5 = half-way between a and b. There are several formulas for lerp, the following one is preferable when working with single-precision-floats, because it guarantees b if t = 1, which other implementations don't.


Now to deltatime. dt is the time that passed between to draw calls. So, instead of using a timer and hoping that it will be precise and behaving the same on all PCs, everytime you start drawing you compare the current time with the stored time from the last draw event. To understand its working, we will assume a (in reality never happening) constant dt of 0.01 (10ms)

If you add dt to t on every draw call (and t initially being 0.0), it will take 100 draw calls until t = 1.0, which means you move from a to b in exactly 1 second, when using lerp. This ratio is always true, no matter the size of dt. Adding it to t of the lerp function, will guarantee moving from a to b in 1 second. Fine. But what if you wanted it to move over 3 seconds? Easy! 3 seconds is 3x the length of an unaltered lerp, so you don't add dt, but dt / 3. This is done by setting up a rate



Of course, the duration can also be shorter than 1 second. Just use rate as described in the code. To evaluate the time that passed between two draw calls, just compare the current time with the stored time of the last call.

That's it. You will now have a smooth transition from a to b that always lasts exactly as long as you defined it.