Datatypes plugin

I've quickly knocked up a Datatypes player for TuneNet - for those arkward files that you have datatypes for, but no TuneNet plug-in!

It will appear on Aminet shortly for testing purposes. Don't expect too much from it yet - it's mono only and often files play at the wrong speed.

I have some questions (the first couple are for Bean probably):

Can I set the priority of the plug-in? At the moment it is taking precedence over the AIFF plug-in, and I really want this to be a "last resort" plug-in for when TuneNet doesn't have a proper one for a certain file. There needs to be some sort of priority setting so I can whack it down to -127 or something.

Can I set the buffer to 8-bit? It appears to be stuck on 16-bit only. Failing that, is there an easy way to convert from 8-bit to 16-bit data. I'm just typecasting the data so I'm surprised it is working at all. This might be where some of the speed problems are coming from, maybe (although it may be the datatypes not reporting the frequency correctly, or something else I've done wrong)

How do I get the data out of a streaming datatype? Is it possible?

Why I can't I give ObtainDataType() a name to try matching against if I specify DTST_MEMORY? This is required for descriptors that need a filename match, you can't do it unless you read from a file (and the clipboard is not a problem as this should be in IFF format anyway)

Oh, and finally, how do I stop TuneNet from remembering my playlist all the sodding time? I'm tempted to revert to the old version to get rid of this new "feature".

Other than that, nice work

Chris

@Chris,

Damn, I just wrote a page long response and the pressed the
wrong sodding button!

Anyway, quick answers.

1/ No, but I'll improve the API for you to do this and will
release it as a service release very shortly.

2/ Frequencies and Channels are internally mixed by TN, but
it expects 16 bit sound. There are several ways to convert
8 bit to 16 bit in the plugin, so I'll gladly help you
out here.

In short - I'll pm you, and send you the latest API.
We can work it out then!

As for saving the playlist this just goes to prove
that you can't please everyone all of the time! But for
you Chris I'll add it to the service list as a preference
option!

Cheers,
Bean.

P.S. Check PM in a moment.

Quote:

Until I add the facility to prefs, press Amiga X when
TuneNet starts to clear.

Cheers,
Bean.

@Chris

To convert from 8-bit to 16-bit you can simply:

uint8 *src;
uint16 *dst;
*dst = (*src << 8)

@Chris

Quote:

Try putting the filename as the first parameter to NewObject(). At least this is what the DTST_MEMORY example in the OS3.9 NDK does, I also remember reading something to the same effect somewhere else, not sure where (autodocs?).

Quote:

This I would say isn't possible with current sound.datatype unfortunately.

I think if the sound.datatype ever were to be updated something like the PDTM_READ/WRITEPIXELARRAY methods of v45+ picture.datatype would be useful, called SDTM_READ/WRITESAMPLEARRAY or similar, that would do sample conversion when necessary.

@salass00

Hmm, it was the AutoDocs that said it was ignored - both on NewDTObject() and ObtainDataType(). If this is not the case then the AutoDocs are wrong! I'll give it a try, thanks.

I think your Sun AU datatype (port?) identifies on the name only, so that will be a good test.

Chris

Quote:

It doesn't (had to check). The name pattern is #? which matches all files. It looks for a ".snd" at the beginning of the file to see if it is of the correct format. The file extension usually used is (confusingly enough) ".au".