Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Combination Circuits/Schematics

For general discussion related FlowStone

Re: Combination Circuits/Schematics

Postby tiffy » Wed Mar 14, 2018 6:49 pm

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.
Attachments
Stereo Audio MP3 Music Player-Amplifier  v1_010.jpg
Stereo Audio MP3 Music Player-Amplifier v1_010.jpg (62.97 KiB) Viewed 19314 times
User avatar
tiffy
 
Posts: 400
Joined: Wed May 08, 2013 12:14 pm

Re: Combination Circuits/Schematics

Postby Spogg » Thu Mar 15, 2018 9:02 am

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
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Combination Circuits/Schematics

Postby tiffy » Thu Mar 15, 2018 10:52 am

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
User avatar
tiffy
 
Posts: 400
Joined: Wed May 08, 2013 12:14 pm

Re: Combination Circuits/Schematics

Postby Spogg » Thu Mar 15, 2018 12:30 pm

Thanks Tiffy.

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

I found 5 is a reasonable maximum, but still not that great.
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Combination Circuits/Schematics

Postby tiffy » Thu Mar 15, 2018 2:06 pm

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.
User avatar
tiffy
 
Posts: 400
Joined: Wed May 08, 2013 12:14 pm

Re: Combination Circuits/Schematics

Postby tulamide » Thu Mar 15, 2018 6:42 pm

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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Combination Circuits/Schematics

Postby tiffy » Thu Mar 15, 2018 11:17 pm

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).
Attachments
SLIDE-OUT WINDOW - A (SLOW).fsm
(132.62 KiB) Downloaded 996 times
User avatar
tiffy
 
Posts: 400
Joined: Wed May 08, 2013 12:14 pm

Re: Combination Circuits/Schematics

Postby tiffy » Fri Mar 16, 2018 6:08 am

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.
Attachments
SLIDE-OUT WINDOW - B (SNAP-OUT).fsm
(169.93 KiB) Downloaded 981 times
User avatar
tiffy
 
Posts: 400
Joined: Wed May 08, 2013 12:14 pm

Re: Combination Circuits/Schematics

Postby Spogg » Fri Mar 16, 2018 12:16 pm

Thanks Tiffy :D

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
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Combination Circuits/Schematics

Postby tulamide » Fri Mar 16, 2018 10:44 pm

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.
Code: Select all
def lerp(a, b, t)
  return (1 - t) * a + t * b
end


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

Code: Select all
def init
  @t = 0.0
  @a = 1.0
  @b = 5.0
  @rate = 1.0 / mytime ## mytime is the duration you want the movement to have (in seconds) ##
end

def draw(v)
  ...
  @t += dt * @rate
  newposition = lerp(@a, @b, @t)
  ...
end


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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

PreviousNext

Return to General

Who is online

Users browsing this forum: No registered users and 56 guests

cron