Hi Everyone!

I cannot understand the IDOS->Createnewproc() function.

I want to play a sound using the datatypes. I first create it with NewDtObject and then play it with the IDoMethod, but I want it to play while my program continues on (Instead of haulting the program while it waits to finish playing the sound). I figured I needed to move it to it's own process, but I cannot figure out how to use the Createnewproc, I just don't understand it.

If anyone could give me a simple example, or point me to a simple example that would be great.

Thanks,

Yogi

@Yogi27

DOS autodoc at bottom of' dos.library/CreateNewProc' has a couple of examples.

You can check os4coding too if it helps (http://www.os4coding.net/search/node/newdtobject) http://www.os4coding.net/forum/play-sound-and-wave-files

Last edited by jabirulo on 04-Jun-2014 at 12:20 AM.

@jabirulo

Thanks for the tips, and I am going to have to study the dos autodoc closer, I just cannot seem to grab the concept I guess.

For Example,

I have code like this:

dtsound = IDataTypes->NewDTObject("some sound file", DTA_GroupID, GID_SOUND, SDTA_SignalTask, (ULONG)IExec->FindTask(NULL), SDTA_SignalBit, SIGBREAKF_CTRL_D, TAG_END);

IIntuition->IDoMethod(dtsound, DTM_TRIGGER, NULL, STM_PLAY, NULL);
IExec->Wait(SIGBREAKF_CTRL_D);
IDataTypes->DisposeDTObject(dtsound);

Question is, how to I get this into a Createnewproc situation?

Thanks,

Yogi

@Yogi27

Quote:

I have code like this: dtsound = IDataTypes->NewDTObject("some sound file", DTA_GroupID, GID_SOUND, SDTA_SignalTask, (ULONG)IExec->FindTask(NULL), SDTA_SignalBit, SIGBREAKF_CTRL_D, TAG_END); IIntuition->IDoMethod(dtsound, DTM_TRIGGER, NULL, STM_PLAY, NULL); IExec->Wait(SIGBREAKF_CTRL_D); IDataTypes->DisposeDTObject(dtsound); Question is, how to I get this into a Createnewproc situation?

I'm decidedly rusty on datatypes sound playing (In AWeb datattypes were used for sound loading but AHI direct for playing), but from scanning the autodocs I think allready you have asynchronous play in place, your just waiting for it to stop so discrading the asynchronicity.


1. SDTA_SignalBit is obsolete (and is infact a mask not a bit so ironically you have used correctly).

You should use SDTA_SignalBitNumber isnstead.

2. Avoid CTRL-C/D/E/F et al for these things allocate your self a signal saves you getting in a mess later.

3. What do you actually want to occur whilst the sound is playing, this hugely affects design, Wait() may be the wrong choice.

rough pseudo code with no error checking (and knowing me 9 or 10 typoes)

soundsignal =   AllocSignal(-1);
wait_mask = 1 << soundsignal | SIGBREAKF_CTRL_C | othersignals

dtsound = IDataTypes->NewDTObject("some sound file", DTA_GroupID, GID_SOUND, SDTA_SignalTask, (ULONG)IExec->FindTask(NULL), SDTA_SignalBitNumber, soundsignal, TAG_END);

while(alive)
{
 signals = Wait(wait_mask)

 if(signals & (1 << soundsignal )
 {
   /* deal with sound being finished */
   /* ie Dispose, feed more sound if continuous etc etc
 }
 if(signals & othersignals)
 {
    Do other stuff, respond to GUI input, render graphics, cook dinner....
 }
 if(signal & SIGBREAKF_CTRL_C)
 {
    /* User abort via via ctrl-c probably burnt the dinner or something ...*/
    alive = 0
 }
}

/* cleanup stuff here */

Last edited by broadblues on 04-Jun-2014 at 02:00 AM.
Last edited by broadblues on 04-Jun-2014 at 01:58 AM.
Last edited by broadblues on 04-Jun-2014 at 01:56 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Yogi27

Looks like you almost answered your own question. The key being that Wait().

The best way is to alloc a signal for this purpose but for testing purposes what you should use is SIGF_SINGLE. IIRC, this is used by both blitter waits and semaphore waits, so can be safe to use if none of those operations are in use. I've used it myself in similar situations and where I need a signal on the spot but without the overhead.

So you can avoid using CreateNewProc() by multitasking in the main program and sending off to-do tasks to the OS. I do it that way. AmigaOS does have a lot of message passing and waiting for a response.

CreateNewProc() in it's simplest form would usually take a start address but you have to watch out as it will create a separate task in AmigaOS. It can be using for creating threads but these aren't real threads in the modern sense and so you can't always share OS data with them for use. So good idea to avoid it as Andy implies in his example. Less complications.

Last edited by Hypex on 04-Jun-2014 at 09:33 AM.

@Yogi27

Quote:

I want to play a sound using the datatypes. I first create it with NewDtObject and then play it with the IDoMethod, but I want it to play while my program continues on

if you just want to play a sound and then do some thing else, and then play sound again, then I think maybe CreateNewProc() is over kill, maybe it be easier or in some cases better to start some other programs to play the sound.

if its a application we are taking about.

Quote:

Question is, how to I get this into a Createnewproc situation?

You most create a function any name will do.

Then CreateNewProcTags() trun this function into new process when you provide the pointer address to it.

One thing you most make shore of is that child process quits before the main program, or else bad things can happen, even if your just playing a sound.

So at the end of your program its normal practice is to signal your child process to quit, maybe in your case you don't need to, but you should however keep track of how many child process that are running, maybe you can use a counter.

You can find a more typical usage of CreateNewProc in Arexx support for MPlayer.

https://code.google.com/p/mplayer-amigaos/source/diff?spec=svn52&r=52&format=side&path=/trunk/src/MPlayer-arexx.c

see the green text.

StartArexx() is called by the main program when it starts, and StopArexx() is called when program ends, the code inside ArexxTask() is what is executed as child process.

ArexxTask() wait until it gets a RxHandler signal or a SIGBREAKF_CTRL_C, when ArexxTask() get a SIGBREAKF_CTRL_C it exits, that last thing it does is signal the main program to inform it that it has finished doing what it was doing, the main program waits for SIGF_CHILD, wait 1 second more to be on the safe side, and program quits.

Last edited by NutsAboutAmiga on 04-Jun-2014 at 11:49 AM.
Last edited by NutsAboutAmiga on 04-Jun-2014 at 11:45 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Thanks everyone for the input.

I will take a look at all the examples you guys have given me, and advice. I think I am getting what CreatenewProcess is. The explanation that is points to a function makes sense to me. Also, the example with how to handle a playing datatype was very useful.

I am having a little trouble with the multitasking/threads etc in my programs, since I am used to programming in the old days with programming languages that really did not support that.

Yogi


- A side thought - we need to replace AHI. (Just my opinion)

@Yogi27

Like NutaAboutAmiga says, CreateNewProc to create a new separate and asynchronous process is overkill. You only need to wait for multiple signals like in broadblues' example. That's how the majority of Amiga programs work and it's much easier.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Yogi27

Quote:

I am having a little trouble with the multitasking/threads etc in my programs, since I am used to programming in the old days with programming languages that really did not support that.

Yes remember back then when I was coding basic, I used counters to create some for of switch based multitasking, relatively easy to do and safe, as no code ever really run in parallel. Well a basic programming language possibly do for some commands, but as basic programmer you never noticed.

Now with a bit more geeky programming language like C, you have all tools in the toolbox, when you have part of your program running in parallel, there are some data you might need to prevent from being modified by etch thread at the same time, or else the result might be data does not exist when a thread try’s to access it, the data is changed in way that was unexpected by the other, so in order to prevent chaos, you will need to force the threads to wait for etch other, this is done with a Mutex on AmigaOS (as they are forbid free, unlike Semaphore).

So by using Mutex at points in the code you want to protect some code from chaos, this what they talk about when they are saying they are making there program thread safe.

You really do not want chaos as it results in dead locks, crashes and all sorts of bad things you can't easy explain, poltergeist syndrome.

Last edited by NutsAboutAmiga on 10-Jun-2014 at 02:26 AM.
Last edited by NutsAboutAmiga on 06-Jun-2014 at 09:51 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Yogi27


Quote:

@jabirulo Thanks for the tips, and I am going to have to study the dos autodoc closer, I just cannot seem to grab the concept I guess. For Example, I have code like this: dtsound = IDataTypes->NewDTObject("some sound file", DTA_GroupID, GID_SOUND, SDTA_SignalTask, (ULONG)IExec->FindTask(NULL), SDTA_SignalBit, SIGBREAKF_CTRL_D, TAG_END); IIntuition->IDoMethod(dtsound, DTM_TRIGGER, NULL, STM_PLAY, NULL); IExec->Wait(SIGBREAKF_CTRL_D); IDataTypes->DisposeDTObject(dtsound); Question is, how to I get this into a Createnewproc situation? Thanks, Yogi

looked at your code again, and it looks like its really wrong choice to create new process to handle this, as its you who prevents the code from continuing with the Iexec->Wait(SIGBREAKF_CTRL_D),

what you normally do if this was a game, is load the sound data at start of the level, and unload the sound data at the end of the level.

You should not load and unload the sound while the your playing the game.

All you really need to do is check if sound is being played or not, and this you do by checking the signal.

Obviously you can't Dispose of dtsound while sound is being played.

See broadblues comment.

Last edited by NutsAboutAmiga on 07-Jun-2014 at 05:42 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Yogi27

Quote:

I am having a little trouble with the multitasking/threads etc in my programs, since I am used to programming in the old days with programming languages that really did not support that.

Well I wouldn't say it's the language that supports but rather the underlying OS. Of course modern languages or variants would be thread aware.

I do see where you are coming from. When old games were programmed there were no special features to encourage "laziness." All code ran in one loop. It controlled everything and had to be multitasking within itself by dealing with tasks one after another. I was pondering this once and had a new found respect for the programmers of old, such as those programming a space ship shoot-up.

I actually had a go at this in BASIC once on the ole A500. And also more recently. The main loop had to keep data and variables for ship positions and bullets. And needed to check for user input to move main ship position, move enemies according to an attack pattern, position bullets, check for collisions and then redraw all sprites. And when the screen refreshed do it all again.

@Hypex

This is exactly what I am talking about. Having the program control everything in the main loop. That is how I learned how to program back in the day. I am trying to get comfortable with not having everything controlled in the main loop.

Should I and Graffias79 decided to code a game, this should be very helpful, since the downside of everything being controlled/updated in the main loop takes alot of work.

Yogi

@Yogi27

I suppose the type of application does matter. I've used the OOP features of AmigaE for skeleton game writing and found I did do the main loop thing. But instead of calling a load of functions in serial order I called a few methods instead. Not that there is much difference as it does the same job.

But I found with OS programming that rarely did I need to think about spawning a child task. One useful thing with AmigaOS is the underlying design of multitasking. At any one time calling an OS function could send off a message and wait. So you can allocate resources, gather all your signals together and then ensure you send off messages to do your bidding. You can then wait on signals and process each as it comes in. In serial order. Of course you need a way to send off a message if the usual OS function for the job waits before returning.