Subject: uade API documentation ?

From: mahenFr
Date: Sun Mar 20 15:22:53 2005

To: UADE-Developer-discussion
Hello everyone !

I was wondering if a documentation of the uade API was available somewhere, a bit like sc68's one (sc68.atari.org). (this would be to add uade players support to an existing simple MorphOS (PPC AmigaOS) player...

I had a look at uade sources, it looks a bit messy, but maybe I can manage anyway...

Well, any piece of advice of welcome :)

thanks !

---

From: Guest
Date: Sun Mar 20 15:24:33 2005

To: UADE-Developer-discussion
I mean, messy due to my lack of experience, because I'm very very bad :)

This would be to add uade support to this player :

http://mahen.free.fr/sc68

(a MorphOS MUI port of sc68)

---

From: mahen
Date: Sun Mar 20 15:25:24 2005

(this was me above btw)

---

From: shd
Date: Sun Mar 20 18:19:12 2005

To: UADE-Developer-discussion
[quote:f412371fbe="mahenFr"]
I was wondering if a documentation of the uade API was available somewhere, a bit like sc68's one (sc68.atari.org). (this would be to add uade players support to an existing simple MorphOS (PPC AmigaOS) player...

[/quote:f412371fbe]

Actually UADE doesn't have an API for communication between clients (players) and the uade process. Currently UADE is very hostile to be directly integrated to any program. Our approach on UNIX has been to run UADE as a separate process, and communicate with shared memory and signals to the client. For exampe, UADE XMMS plugin works like this:

 xmms (contains uade plugin library) &lt;-A-&gt; uade &lt;-B-&gt; soundcore &lt;-C-&gt; eagleplayers

&lt;-A-&gt; means communication by shared memory and signals
&lt;-B-&gt; means instruction set simulation interface (works through  m68k trap commands command)
&lt;-C-&gt; Eagleplayer API

It has been intentional that we don't have an API. However, we are still planning a next version of UADE that supports easier integration with other programs.

At the current code base, you may want to write a 'slave module' into uade process. Look at src/xmms-slave.c, src/unix-shell.c and src/amiga-shell.c. Harry 'piru' Sintonen, the MOS developer, is rather familiar with this topic. You might talk to him about possibilities of integrating UADE into an Amiga environment.

ATM I encourage you not to link uade program directly to your player, but rather run UADE as a server process for your player process. IPC can be easily implemented in UADE's slave modules. Would you tell us what kind of IPC you had in mind? Or do you absolutely need direct code module linking? Direct linking is not impossible either - it has been done in CVS versions..

Sorry for the messiness in code ;) We do accept patches to clean up the situation, but I don't think many people will want to clean that architecture for us..

shd / uade team

---

From: shd
Date: Sun Mar 20 18:29:05 2005

To: UADE-Developer-discussion
[quote:7a5923f838="Anonymous"]I mean, messy due to my lack of experience, because I'm very very bad :)
[/quote:7a5923f838]

We know it's messy. No need to take back what is true ;)

[quote:7a5923f838]This would be to add uade support to this player :
http://mahen.free.fr/sc68
[/quote:7a5923f838]

See my earlier answer. I was thinking it should be relatively simple to create a thread from slave module, and run the GUI engine in that thread. The thread would give commands to the uade process with some interthread IPC method. However, this is hard if you still want to run sc68 inside the same memory space :(

shd / uade team

---

From: mahen
Date: Sun Mar 20 18:38:40 2005

To: UADE-Developer-discussion
thanks for the quick &amp; complete answer !!! 

Well, erm, as I told earlier, I really have little experience :) So regarding the little player, for the time being there are only two processes :

- the one dealing with the MUI user interface that sends orders through the message port to 
- the second process that uses the sc68 api directly (checks if a message arrived after each buffer calculation) and sends the sound buffer to the AHI audio system.

So I guess I have to add a kind of layer to enable the use of several different "players" (that is to say sc68 and uade).

Well, what would be the wisest choice, I really don't know what is the best way of doing this kind of things ? :)

---

From: mahen
Date: Sun Mar 20 18:40:16 2005

To: UADE-Developer-discussion
Oh, I've just seen you answered meanwhile, so sorry if I ask a question already answered :)

Thanks ever so much for the team for this amazing work :)

---

From: shd
Date: Sun Mar 20 18:48:02 2005

To: UADE-Developer-discussion
[quote:4b445d88e4="mahen"]
- the one dealing with the MUI user interface that sends orders through the message port to 
- the second process that uses the sc68 api directly (checks if a message arrived after each buffer calculation) and sends the sound buffer to the AHI audio system.
[/quote:4b445d88e4]

If you want to have both sc68 and uade in the same process, you may have to prevent global symbol collisions. Colliding global symbols can be removed with objcopy tool (comes with GNU compiler tools).

Also, it doesn't require very big changes to make uade runtime a callback system so that you can call a function from uade and it returns an event and sample data. Basically your main program would call sc68 and uade when appropriate, exchange messages with the MUI process, and write sample data to AHI driver.

Where is the source code for sc68mui? I can't help you unless you provide source. In fact, you have to provide source if you are going to link with UADE.

---

From: mahen
Date: Sun Mar 20 18:52:04 2005

To: UADE-Developer-discussion
Yep, this is actually the way I thought I would do it, but I didn't know if it was the best way !

You may find my (crappy as it's my first Amiga/MOS program) sourcecode at :

http://mahen.free.fr/sc68/sc68src.lha

---

From: mahen
Date: Sun Mar 20 18:53:11 2005

To: UADE-Developer-discussion
BTW : ** thanks ** for your answers

---

From: mahen
Date: Mon Mar 21 14:14:27 2005

To: UADE-Developer-discussion
I've had a look a bit more at the uade source code. 

Tell me if I'm wrong, but in order to use it in a player, I have to make use of slave.interaction that is used in uade.c : uade_interaction. However a couple of things disturb me, for instance, the messages sent through the 68k emulation to uade, that are then printed to stderr by uade_get_amiga_message when some exceptions in the 68k emu occur. Well, I guess this would have to be modified to send some information to my player through a message port rather than just printing it ? 

Pfew, I'm a bit lost in all this, tell me if I'm missing something important :)

Anyway, I HAVE to create a uade process, as I have to start the 68k emulation with start_program(), right ? (so 3 processes : one for the MUI GUI, one for the piece of software that gets order from the gui and launches / quits the right player, and one for uade ?)

:)

- mahen, that keeps annoying ppl :)

PS : to sum things up, I have to use this slave.interaction to give order from my player to uade, and I have to use uade_get_amiga_message to check if something has to be reported from uade to my player ? I guess things such as seeking are not supported (doesn't matter too much :).

Actually, what I was first planning to do, is use uade the way I use sc68 : specific things to initialise, open AHI device, ask sc68 via a single function to calculate a sound buffer, send it to AHI, check if a message came from the GUI, and so on. Is it possible with uade ? Or does it require deeper modifications to the uade source code ?

** sorry again for bothering you &amp; thanks for everything **

---

From: shd_
Date: Mon Mar 21 14:39:34 2005

To: UADE-Developer-discussion
[quote:2ef3713e77="mahen"]
Tell me if I'm wrong, but in order to use it in a player, I have to make use of slave.interaction that is used in uade.c : uade_interaction. However a couple of things disturb me, for instance, the messages sent through the 68k emulation to uade, that are then printed to stderr by uade_get_amiga_message when some exceptions in the 68k emu occur. Well, I guess this would have to be modified to send some information to my player through a message port rather than just printing it ? 
[/quote:2ef3713e77]

Yes, atm interaction is what you want. We originally created interaction for command line interfaces, but it must be redone and unified with the rest of the slaves. For example, xmms-slave.c is used to control UADE with GUI, but it does not use interaction. However, unix-shell-int.c uses interaction.

SCORE notifies simulator of events that semantic meaning with respect to eagleplayers. uade_get_amiga_message() handles these events. For example, when a song ends, uade_get_amiga_message() calls uade_song_end() which in turn calls slave.song_end() to message the slave.

Delivery of messages from amiga to simulator is the same with or without interaction. But delivery of events from UI to simulator depends on whether interaction is used or not. With interaction new interactive events are delivered once per simulated vertical blanking to the simulator. Without interaction new interactive events are delivered by various mechanisms such as signal handlers and shared memory. Signals and shared mem are tricky, and they shouldn't be used.

The event mechanism is something I should really fix in the near future. Perhaps it would be better if you waited for a month, and let me release a version of new development branch. I would fix the interface so that it's much less kludge to integrate uade to other programs. I have actually done this in the past by creating a callable shared lib version of uade, but it was too experimental to be released.

[quote:2ef3713e77]
[/quote:2ef3713e77]

This is something I can't comment on, because I don't yet know how you will interface with uade.

---

From: mahen
Date: Mon Mar 21 14:56:44 2005

To: UADE-Developer-discussion
shd: thanks again for the prompt reply. Well, I think it would be wiser to wait for the next release then. It will be cleaner and easier.

thanks again :)

---

From: Guest
Date: Sun May 8 18:22:42 2005

To: UADE-Developer-discussion
MorphOS supports DCOM, no?

Or was IPC?

---

From: mahen
Date: Sun May 8 19:18:04 2005

IPC :)

DCOM is windows-related only, no ?

---

From: Guest
Date: Sun Jun 5 01:41:01 2005

To: UADE-Developer-discussion
IPC is multiplatform? Could be nice using a multiplatform one and free :)

---

From: mahen
Date: Sun Jun 5 17:58:13 2005

To: UADE-Developer-discussion
Well, IPC = inter-process(es) communication, so in my mind it was just a general concept but I guess you're refering to some IPC in particular :)