I tried the datatypes for 32-bit, they work well

.

Midi datatype or just 32bit Datatypes in general.

Do we have a midi datatype descriptor in Devs/Datatypes?

If not we'll need to make one.

pcx and targa Miker

After I.A. converted the source code from AMiGA MIDI datatypes to AROS MIDI datatypes and fixed numerous errors, I compiled Su AROS One 64-bit Native with GCC without any errors. Now I'm not sure if the MIDI datatype was converted correctly by I.A.

@AMIGASYSTEM

Could you please post your WildMidi source code including the GUI so I can see how it plays midi files for comparison with the midi datatype.

Also, I'll compile midi datatype on my system then test it to see if I get any errors.

I'm going to order some SSD adapters so I can setup AROS 32bit and 64bit test systems on real hardware. Testing Datatypes for example is much better on real hardware which seems more responsive in my opinion compared to a virtual machine in VirtualBox.

I'm not sure if WildMidi supports MIDI data types; with WildMidi, I play MIDI files using Timidity (Software Musical Instruments).
WildMidi also converts MIDI files to audio files.

If you want to run some tests, do them directly with WildMidi; the GUI might skew the results.
You can find the latest version of WildMidi, v0.4.6, on Arosarchive; I compiled it a few weeks ago.

https://arosarchi...6-aros.zip
https://arosarchi...os-v11.zip

I've been doing some compiling and testing for Datatypes over the last several days. I've made progress! ;-)

Here are some screenshots from my latest efforts at writing, compiling & testing new Datatypes.

These screenshots are compiling & testing the current release candidate for the new Targa Datatype. It has taken a couple years to get here!

Here is the current release candidate for the new Targa Datatype.

The archive contains the datatype & descriptor compiled for AROS x86.

The build system files are the source code. Copy the Tga folder & it's contents to Workbench-Classes-Datatypes then compile for x86 or you may try to compile x86-64.

This is a more fully featured Targa datatype than the one in Contrib. It allows loading & saving 8,16,24,32bit images. Run Length Encoding works also. Better yet it's an AROS datatype! So it can be placed in our source code for all to enjoy. :-)

In a few days I'll post it to AROS Archives if all goes well. Please report to me any errors or issues.

Thanks for your patience. ;-)

For my next datatype projects I'm looking into MIDI Datatype, MP3 Datatype and revising my PCX Datatype. I've started JNG, MNG.

In the process of rewriting my PCX Datatype I plan to write an instructional PDF about writing Picture Datatypes. Later I may expand to Sound & Text Datatypes.

why datatypes are not in aros official repository?

Some Datatypes, and other software have copyrights from other developers not AROS Development Team. So their source code is located in Contrib not Main.

I'm currently revising some of the read functions for my PCX Datatype.

It's actually going quicker than I expected. The write functions need some cleanup & revision also. We may have another new datatype in a couple weeks if all goes well.

I wrote the majority of my Targa & PCX Datatypes about three or four years ago when my programming skills were still under development. The code is so messy!! But it works!

Over the past week I have spent some time re-writing all of the Read functions of my PCX Datatype because I want to use it as an example for an instructional PDF about "How To Write Datatypes".

I revised all the functions used to read 8bit & 24bit PCX images. I also completely revised Read RLE to the extent that when I started to compile it I didn't expect it to work without a lot of error fixing & troubleshooting.

There were many small compile errors of course such as undeclared functions or variables, missing parentheses, etc. But after a while it compiled correctly! Nice start. :-)

But I still didn't expect it to work.

So here's the first screenshot of the new PCX Datatype in action...almost working!

In the previous screenshot & in several other test images there's a small region of distorted pixels in the top left corner. At first I thought it was because of padding bytes. But then I discovered the problem.

In the two new screenshots you can see the layout of the struct PCX_Header which consists of 128 bytes. But I wasn't reading the last 54 bytes because it's all zeros. But that's what caused the offset errors.

I had to use the Seek command to set the file pointer to skip the last 54 bytes to arrive at the beginning of the image data. For 8bit images the ColorMap also immediately follows the image data. On the previous attempt the 24bit images had artefacts & 8bit didn't load at all.

After skipping the unused bytes in the header the images, both 8bit & 24bit loaded correctly! So, now the Read functions are working nicely.

So that you can see what is going on inside the pcx datatype here is the source code for my new read functions. It looks nicer & cleaner.

It's layout is based on AROS PNM datatype & my new Targa Datatype.

The includes & initial layout is from PNM datatype. The Read functions themselves & many of the D(bug) statements are copied from Targa Datatype. Hopefully I have converted them all to PCX Datatype;-)

The individual pcx_color & pcx_header structs are from samples. The Read RLE function is based on a sample provided by Copilot AI about how to decode PCX RLE (byte level run length encoding).

It all works together nicely though. I've already prototyped all of the Write functions as well. But I need to copy them from my old PCX Datatype sources then clean them up and rewrite them.

Over the past few days I copied the pcx write functions from my old pcx datatype sources from a few years ago. It is functional and it loads & saves 8bit & 24bit rle compressed pcx images. But the code needs to be cleaned up & revised next week.

For example WritePCX_Line uses bit depth to prepare either 8bit indexes or 24bit pixels then calls WritePCX_RLE. It should be split into two functions: WritePCX_LUT8 & WritePCX_Truecolor. Then code can be added to write 1,2,4bit planar pcx.

There's still much work to be done!