[Libff-devel] Re: libff API

[Rodrigo D. <cu...@uo...>]

Johann Deneux wrote:

>On Fri, 15 Feb 2002 20:41:27 -0200
>"Rodrigo Damazio" <cu...@uo...> wrote:
>
>>Johann Deneux wrote:
>>
>>>On Fri, 15 Feb 2002 11:55:38 -0200
>>>"Rodrigo Damazio" <cu...@uo...> wrote:
>>>
>>>>[...]
>>>>
>>>I think it would be nice to be able to store/load effects to/from file=
s. I
>>>already started a tool to edit effects (although its development is no=
t
>>>going forward very fast).
>>>
>>        Sounds nice...what file format are you using?? I could include=20
>>this tool in the libff package, and add support for loading its files...
>>
>
>Right now, it's not implemented. I started to hack Immersion Studio file=
s,
>but using a more readable format wouldn't hurt. I don't know much about
>XML, but an ascii-based file would be fine.
>
        Perhaps XML would be nice, since it's ascii-readable and very=20
well-structured ...

>>>What I would need is the following:
>>>- Create an effect/Load it
>>>- Update it (restart it if necessary ?)
>>>
>>        Do all devices support updating an effect while it's playing??
>>
>
>Probably not, as the DInput API mentions this issue. In that case, one s=
olution
>is to stop-update-restart effect. Not very nice, but if we use the trick=
 you
>describe below about posing we could avoid some problems related to the =
envelope.
>
        Yes, I guess so...there really ain't much we can do if the=20
device doesn't support something...

>>>- Control the playback (start, stop, pause -the later does not seem to=
 be supported by I-Force devices- )
>>>
>>        Perhaps we could emulate pause with a stop, then resume with=20
>>restarting the effect with a 0-attack-time envelope??
>>
>
>More generally, we need to know when exactly we paused. After that we ne=
ed to
>update the envelope or the time-offset for periodic effects. There is a =
nasty
>case however:
>  --X-   ----
>_/    |_/    |
>=3D=3D=3D=3D=3D=3D=3D
>^ One period
>
>If we pause at X, we can change the envelope, but we must restore it whe=
n the
>effect restarts (it is possible to play an effect several times).
>Anyway, one role of libff is to unload this piece of work from the kerne=
l driver.
>
        Hmmm I guess the main problem here would be keeping track of=20
time, since not even the kernel knows about it - only the device...if we=20
pause the effect in the middle of the attack phase of the envelope, for=20
example, we have to set the attack level accordingly...like this - if=20
the effect should play 5 times, and we pause in the attack phase of the=20
second time...to unpause it, we'll have to: set envelope/update=20
effect/play once/set old envelop back/update/play 3 more times...and=20
make sure all this happens as fast as possible...this will be a pain to=20
code...but anyway...

>>>- Query the status of an effect (playing, stopped)
>>>
>>>It may also seem useful to be able to query the state of the device (i=
t
>>>it's accepting new updates), but I think we can stick that into the ef=
fect
>>>status query.
>>>
>>        Hmmm what if we have no effects and want to query the device??
>>
>
>My first idea was that we should be able to ask the device if it's ready=
 to
>accept an update. For example, with iforce devices, we must wait that th=
e device
>acknowledges the update before performing a new update. However, it is o=
k to
>update effect 2 even if we haven't yet received the ack for effect 1. Th=
at's why
>my second thought was to do it on a per-effect basis.
>
        I see...that's possible...if the device is not ready, what=20
should we do?? Make it async and return an error, or should we just sit=20
and wait 'til it's possible??

>
>Maybe there are properties of the device itself that could be queried, t=
oo.
>Do you see any such dynamic property (ie beside the name, type, effects =
supported
>by the device) ?
>
        That'd be stuff like gain, which actuactors are enabled, etc...
        I suppose there is another lib which can be used for reading the=20
device data?? Like axes position, buttons, etc...so we don't need to=20
worry about that, right?

>If there is no effect, the status of the device is obvious: it's doing
>nothing (what could it do ???)
>
        It could be playing effects from another application =3Dc))

>>>The question is what should be left to the user, and what should be ha=
ndled by the API ?
>>>
>>        Exactly...
>>
>>>Other question: what's your opinion about the shared parameter block i=
ssue ? It's seems we are
>>>forced to go for the restrictive 1-parameter 1-effect scheme on the dr=
iver side, but that does
>>>not mean we cannot try to emulate it on the API side.
>>>
>>        I'm in favor of it - in fact the API has already started with=20
>>that idea...but probably(and specially if the kernel chooses 1-to-1=20
>>scheme), updating a block will only change the effects where it is used=
,=20
>>if the effect itself is updated...
>>
>
>We will need to define clearly what we mean by effect. To me, it looks
>like we should apply the change as soon as the parameter block is change=
d.
>
        An effect is a group of properties that will generate a force...

        Btw, should we implement effect groups, like in Immersion=20
Studio? It could be useful...

>>>Btw, I could direct people I know are interested in force feedback to =
your
>>>sf project page. Do you plan to use mailing lists to communicate, or t=
o
>>>use the forums instead ?
>>>
>>        Sure...I'll set up mailing lists...I'll add you there too ok?
>>
>
>Sure, please do it. Or tell me when it's done, I don't know if you can s=
ubscribe
>other people than yourself.
>
        It's done, you're here now =3Dc)

Rodrigo

--=20
*******************************
* Rodrigo Damazio             *
* *************************** *
* cu...@uo...           *
* rod...@po... *
* ICQ: #3560450               *
* http://www.vros.com/cuddly/ *
* *************************** *
* Engenharia da Computa=E7=E3o    *
* Escola Polit=E9cnica          *
* USP - S=E3o Paulo             *
*******************************