New Sound Datatypes

[miker1264]

we trust in you 

Thanks. This one is a little perplexing at the moment.

It fails to return an empty datatype object but it successfully returns a datatype for an existing file! Hmmm...

But Save As IFF for Sound Files works in MultiView! 

But I think I'm close to a solution. Looking at BMP datatype and other standard datatypes when creating an empty object the OM-NEW leads to the Load Function. In turn the Load Function tests for DTST_RAM as opposed to DTST_FILE and it looks for an empty filehandle. If it finds DTST_RAM & an empty filehandle it's an empty object so it returns the empty datatype object as requested.

However we unfortunately only have two sound datatypes for AROS those being Wave Datatype & 8SVX Datatype. So I examined 8SVX datatype first looking at OM_NEW & Read8SVX. But the Read Function doesn't test for DTST_RAM & an empty filehandle. Instead it says If(sourcetype != DTST_FILE) ... return FALSE; So the datatype simply fails to return anything in that case. That's wrong!

After examining Wave Datatype OM_NEW it also doesn't test for DTST_RAM & an empty filehandle. Hence the problem of not returning an empty sound datatype object. Mystery solved? We'll see. 

I will modify 8SVX Datatype first then recompile and test again. If it returns an empty datatye...then problem solved.

[miker1264]

Good news!

After I modified both 8SVX & Wave datatypes to return empty objects I was able to use DTConv to convert 8SVX to Wave.

Making some progress. 

The next step is to incorporate the ConvertPicture & ConvertSound into MultiView for Converting Datatypes..

[Samurai_Crow]

After working with Sound Datatype Conversion for a short while I've concluded that we need more datatypes!

Maybe MOD, MED, MIDI, OGG, MP3 & WMA to start.
We already have WAV & 8SVX.

The old 68k versions of AHI for AmigaOS 3 came with a Protracker MOD datatype in 68k Assembly with source.  Also included was a Filesave driver to export any audio to an AIFF recording.  Maybe that could be of some use.  It's all open source.

The datatype system on AmigaOS prior to version 4 on PPC didn't support streamed formats nor does the IFF standard fully.  Maybe AROS should follow suit with a child of the base class for streamed audio formats.  Maybe it could even wrap all the methods of the Tapedeck gadgetclass.

I've got one other idea for MIDI and modules.  I wanted to write a capture AHI driver that could capture the output of any music program to a hybrid format between MIDI and MOD formats.  It would store the samples at the beginning using 8SVX, 16SV or even a Raw sample variant like a mod file.  Then it would record the commands set for each voice by intercepting the AHI command calls and hashing out the duplicates on every tick.  There would be separate playlists for each voice stored to the file but once the channel closed, it would write out the contents of the hashed commands as enumerated structures.  This format could capture any module format and reduce it to such simplicity that it could reduce to a copper-based register feeder on chipset-capable Amigas or export to C source directly on other systems.

I started the last idea myself back in college in 2007 but did it wrong.  I tried converting Protracker formatted modules to C source but the hardware banging driver was too unstable for the multitasking and had to use mix mode on UAE.

[miker1264]

@Samurai_Crow

"I started the last idea myself back in college in 2007 but did it wrong.  I tried converting Protracker formatted modules to C source but the hardware banging driver was too unstable for the multitasking and had to use mix mode on UAE."

That seems like a nice project to finish. Lots of good ideas. 

I have a few small projects I'd like to finish as well. Time marches on and sometimes they get left behind.

I believe there is a MIDI datatype already. I haven't looked at it. As for MP3 there is library mpega for conversion. Just an idea.

[Samurai_Crow]

@Samurai_Crow
I believe there is a MIDI datatype already. I haven't looked at it. As for MP3 there is library mpega for conversion. Just an idea.

MIDI should be possible based on Timidity.  The hard part of streaming MP3s from a datatype is that it loads the entire file into RAM before it processes it.  I don't know how AROS does it but AmigaOS 4 had to add an API change to allow streaming of portions of a file instead.

[AMIGASYSTEM]

Hi Samurai_Crow, I don't know if I understood correctly, I'm not an expert developer like you, on AROS the MP3 streaming works well with MPlayer.

Regarding MIDI on AROS there is a "wildmidi" Player that works very well only it works only on command line, it doesn't support play from Icon and it doesn't have a GUI. I think that a Midi.datatypes would allow Multiview to play also a Midi.

[Amiwell]

HarmonyPlayer works well with midi files, timidity must be installed

[AMIGASYSTEM]

Thanks, I don't remember that HarmonyPlayer plays Midi files, but it is not associated to an icon, every time for a Midi file you have to open the program first and then load the file.

When you have to test or listen to Midi files from different paths, you need a Player with a small and simple GUI to play directly a Midi file with one click either from Wanderer or from a Filemanager.

[Amiwell]

ok i understand

[Amiwell]

You can always create a button in Dopus that launches the program

[AMIGASYSTEM]

It doesn't change anything from Wanderer, moreover from Dopus4 co HarmoniPlayer the Commands included in the Icon Tooltypes are not executed ! so it can't open the GUI !

[Amiwell]

i understand

[Samurai_Crow]

Hi Samurai_Crow, I don't know if I understood correctly, I'm not an expert developer like you, on AROS the MP3 streaming works well with MPlayer.

That's not the problem.  The problem is that the file identification rules require access to the whole file.  This means that Datatypes.library has the entire 5+ MiB MP3 file sitting in RAM before it even tries to play it.  Once it is playing, there are no problems.  Only the MP3 file identification problem is there.  Streaming assumes that the whole file doesn't NEED to fit in memory at a time.  Datatypes aren't aware of that type of file streaming.  It's reasons like that that the Anim file loads into RAM before it starts to play even though the file is large.  IFF is not streaming aware and Datatypes.library was designed around the idea that importing to IFF would be all that was needed.

[AMIGASYSTEM]

Thanks for the reply

[Samurai_Crow]

No problem.  Sorry for the late response though, I only skimmed over your post earlier and only just now realized that you needed further explanation.