@jabirulo I've uploaded a quick patch. It's still called 3.14 but the build number now is 233. Loading .pls playlists at startup via ToolType should work now. :)

@jabirulo Oh, then new play list format from tooltype is probably buggy. :( Ok, something more to fix. Guess I'll just patch v3.14 and let you know when it's done! Sorry bout that!

3.14 is out, restoring compatibility with playlists generated by older versions of ATunes and improving playlist loading in general.

@samo79 got it! :)

@zzd10h
Quote:
Most likely this week! :)

Ok, the plan is as follows:

1. Repair PLS and M3U loading.
1.1 Read tag info stored in PLS and M3U along the way

2. Accept a headerless playlist when it's passed to AmigaAMP as a single filename. Assuming that if a user tells AmigaAMP to load a specific headerless text file he knows what he's doing.

3. Don't accept a headerless playlist when it's found by AmigaAMP while scanning a directory because it's not necessarily a playlist but could be a readme file as well.

@EgilLunde
The most common file formats work right out of the box without the need for extra plugins. Supported file formats are MP3, MP2, M4A, OGG, AIFF, WAV, MOD, XM, S3M and many more. For some more exotic formats you could check if there's a TuneNet plugin for that. TuneNet plugins will also work with AmigaAMP3.

Just checked aTunes. It names the file m3u but it's in fact an unformatted text file. Loading unformatted text files as playlists caused all sorts of problems in the past so I want to get rid of it.

So instead of creating a playlist like this:
Quote:

it should look like this:
Quote:

or like this:
Quote:

The length is always specified in seconds.

Unfortunately the current playlist loader in v3.13 gets very confused about file paths. Sometimes only absolute paths work, sometimes only relative paths work. I need to fix this.

@zzd10h I'll contact you about restoring compatibility with aTunes. One way or the other, we'll get it back to work! I promise! :)

I didn't mean to break M3U! When I quickly tested it, it still worked. Maybe I haven't tested it well enough. I'll fix it!

I will also have a look at .pls file name parsing.

Ok, found the issue:

I've got two registered applications, called "AmigaAMP-Prefs" and "AmigaAMP". When I disable AmigaAMP but leave AmigaAMP-Prefs enabled then even AmigaAMP can still send messages.

Disabling AmigaAMP-Prefs as well fixes it.
Registering AmigaAMP under a different name, e.g. "AmigaAMP-Player" fixes it.

Is it wrong to register a new app under a name that's a substring of an already registered one?

Is it wrong to use dashes in app names?

Hi,

I don't understand what the "Applications List" in Prefs/Notifications is for. I thought that when I untick a certain application it will stop the ringhio server to accept nitification requests from that particular app.

But this doesn't seem to be the case. Even if I remove the checkmark my simple code



still causes a message to pop up. Am I doing something wrong?

Thanks,
Tom

@trixie

The first post was just a copy of the original SDK ReAction window example code. In AmigaAMP I'm using your method which I like better. :)

No need to argue :)

The skinned mode is definitely meant to be completely non-Amiga. In fact it's completely non-Windows and non-Linux as well. It's a proprietary GUI style which I tried duplicating and it was fun to do.

Actually I like this GUI. Not in general but for this particular application. I use it on Windows and Gnome Desktop, too.

The only thing I want to do regarding this matter is fix the broken window moving routine.

The coming release will properly register as an application using application.library and send out ringhio messages.

Loading whole directories will only load those files which match the file pattern you've set.

For a true Amiga-like GUI the next release will feature proper ReAction windows for main, playlist and metadata info in non-skinned mode.

But those three are a different story not to be discussed here. :)

Ah thanks! :)

I was thinking of option #2 but I don't have the time to implement that.

However, option #1 sounds like a good idea. I'll try that.

@trixie
I'm getting frequent WMHI_CHANGEWINDOW messages while moving the window, at least on my 4.1 Update 6 system.

Hi all,

I'm trying to 'dock' two windows to each other, i.e. when you move the 'master' window then the 'slave' window moves along with it.

I've done this by trapping WMHI_CHANGEWINDOW on the main window and then calling SetAttrs() for the slave window with the new position.

However, the slave window doesn't move along with the main window while dragging. Instead, when I release the main window then the slave window will follow the track that the main window took. This looks quite funny but certainly isn't right. Am I doing something wrong? Is there some better way to achieve this?

Thanks for your help.

Here's the code:

;/* WindowMoveTest
gcc -o WindowMoveTest WindowMoveTest.c -lauto
quit
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <dos/dos.h>
#include <classes/window.h>
#include <gadgets/button.h>
#include <gadgets/layout.h>

#include <proto/intuition.h>
#include <proto/exec.h>
#include <proto/window.h>
#include <proto/layout.h>
#include <proto/button.h>

enum {
WID_MASTER = 0,
WID_SLAVE,
WID_LAST
};

enum {
OID_MASTER = 0,
OID_SLAVE,
OID_LAST
};

int main() {
ULONG mxpos;
ULONG mypos;

// Make sure class files were loaded.
if ( WindowBase == NULL || LayoutBase == NULL || ButtonBase == NULL) {
return RETURN_FAIL;
}

struct Window *windows[WID_LAST];
Object *objects[OID_LAST];


objects[OID_MASTER] = IIntuition->NewObject(NULL, "window.class",
WA_ScreenTitle, "MasterWin",
WA_Title, "MasterWin",
WA_Activate, TRUE,
WA_DepthGadget, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, TRUE,
WA_SizeGadget, FALSE,
WA_Left, 100,
WA_Top, 100,
WA_Width, 200,
WA_Height, 100,
TAG_DONE);

objects[OID_SLAVE] = IIntuition->NewObject(NULL, "window.class",
WA_ScreenTitle, "SlaveWin",
WA_Title, "SlaveWin",
WA_Activate, FALSE,
WA_DepthGadget, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, FALSE,
WA_SizeGadget, FALSE,
WA_Left, 100,
WA_Top, 200,
WA_Width, 200,
WA_Height, 100,
TAG_DONE);

if (objects[OID_MASTER] != NULL && objects[OID_SLAVE] != NULL) {
// Open the windows.
windows[WID_MASTER] = (struct Window *)IIntuition->IDoMethod(objects[OID_MASTER], WM_OPEN);
windows[WID_SLAVE] = (struct Window *)IIntuition->IDoMethod(objects[OID_SLAVE], WM_OPEN);

if (windows[WID_MASTER] != NULL && windows[WID_SLAVE] != NULL) {
// Obtain the master window wait signal mask.

uint32 signal = 0;
IIntuition->GetAttr(WINDOW_SigMask, objects[OID_MASTER], &signal);

// Input Event Loop

BOOL done = FALSE;

while (!done) {
uint32 wait = IExec->Wait(signal | SIGBREAKF_CTRL_C);

if ( wait & SIGBREAKF_CTRL_C ) {
done = TRUE;
break;
}

if ( wait & signal ) {
uint32 result = WMHI_LASTMSG;
int16 code = 0;

while ((result = IIntuition->IDoMethod(objects[OID_MASTER], WM_HANDLEINPUT, &code)) != WMHI_LASTMSG) {
switch (result & WMHI_CLASSMASK) {
case WMHI_CLOSEWINDOW:
windows[WID_MASTER] = NULL;
done = TRUE;
break;

case WMHI_ICONIFY:
IIntuition->IDoMethod(objects[OID_MASTER], WM_ICONIFY);
windows[WID_MASTER] = NULL;
break;

case WMHI_UNICONIFY:
windows[WID_MASTER] = (struct Window *)IIntuition->IDoMethod(objects[OID_MASTER], WM_OPEN);
break;

case WMHI_CHANGEWINDOW:
IIntuition->GetAttrs(objects[OID_MASTER], WA_Left, &mxpos, WA_Top, &mypos, TAG_END);
IIntuition->SetAttrs(objects[OID_SLAVE], WA_Left, mxpos, WA_Top, mypos+100, TAG_END);
break;
}
}
}
}
}

/* Disposing of the window object will also close the window if it is
* already opened, and it will dispose of the layout object attached to it.
*/
IIntuition->DisposeObject(objects[OID_SLAVE]);
IIntuition->DisposeObject(objects[OID_MASTER]);
}

return RETURN_OK;
}

Hi,

I've found it to be easier to share the folder on the Windows machine and access it from the Amiga side using smbfs.

For example:

smbfs Workgroup=WORK User=Me Password=Secret Service=//Computer/Share DEVICE=PCshare: VOLUME=PCshare

@tboeckel

I think it's more likely an issue with the cs4281.audio driver. I don't get this static noise on my classic Amiga running the same AHI version.

I've removed all of the unused drivers and so far the problem of ahi.device being unavailable hasn't occured any more. *fingers crossed*.

However, even when I start the mixer before anything else the initial crackling sound remains.

I've got:

System:> version ahi.device full
ahi.device 6.6 (27.09.2005)
?1994-2005 Martin Blom. 603 version.
System:> version cs4281.audio full
cs4281.audio 5.3 (27.02.2009)

The number of channels is already set to 10, so that shouldn't be a problem.

I just noticed that the AHI and AudioModes directories are full of unused drivers. To be on the safe side I've deleted all the unused ones and kept cs4281.audio only. Let's see if this helps.

By the way, I've also noticed that the very first sound that is played after opening ahi.device starts with a short burst of static just as if it first plays an uninitialized buffer before playing the actual sound data. As long as the application keeps the device driver open this doesn't happen again. As soon as ahi.device is closed and re-opened the initial burst of static occurs once more.