Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: amigakit on November 19, 2019, 03:11:28 PM
-
Recently, AmigaKit Ltd acquired AK-Datatypes (http://forum.amiga.org/index.php?topic=74284.msg845220#msg845220).
Since then development has been ongoing and we are very pleased to confirm that the package has been internally updated significantly.
The development will continue and a new public release for OS3 will be made shortly.
The question we have is should we release this as free downloadable archive to the Amiga community and ask for a small donation to cover the costs of ongoing development? Alternatively should we charge a nominal fee up front?
Our initial thoughts are to release it for free, and if we get enough donations then proceed to the next revision and so on. If we fail to receive enough donations then move to a commercial model to sustain it's ongoing development.
I welcome the feedback. Please indicate if you would be willing to support this project by a donation so we can gauge the response.
Thanks!
-
Greetings!
It would be helpful to know what "AK-Datatypes" is, and how it might benefit me.
Sorry for my ignorance
-
This one looks like an easy to understand summary:
http://www.mfischer.com/legacy/amosaic-paper/datatypes.html
-
Or in short:
Version 3.0 added datatypes support which allowed any application that supported datatypes to load any file format supported by datatypes. Workbench could load any background image in any format if the required datatype was installed. A tiny application called Multiview was included that could open and display any supported file. Its capabilities were directly related to the datatypes installed in Devs:Datatypes. The established AmigaGuide hypertext system gained more usability by using document links pointing to media files, for example pictures or sounds, all recognized by the datatypes.
https://www.wikizero.com/en/AmigaOS
-
It would be helpful to know what "AK-Datatypes" is, and how it might benefit me.
https://aminet.net/search?name=ak&path=util/dtype
-
Datatypes are something I do struggle with as I don’t like to willie-nillie load my OS up with DT’s I don’t understand. I have tried various DT’s from AmiNet without a whole lot of success. That’s where an all inclusive, functional, clean, manageable & easy to understand DT package would be so brilliant.
When you state “small” & “nominal” that leaves little to go by for the target consumer. Only you know the cost of your current development. Also, in either case (donation or fee), you should be able to guesstimate the return on investment. IMHO, the donation method can sometimes come up a little short and inhibit updates. However, if the fee were truly affordable and would ensure continued updates in a timely manner, I, myself would rather pay a set price for a quality product (I have never used the product you acquired). I would even be willing to throw in a few bucks for updates if it were as easy as using PayPal and downloading.
Could you maybe give us a clue as to what an upfront fee might be? I think that would really get you more feedback. 8)
Also, thanks so much for the development of this product. Any ETA on release? Any thoughts on how it will be distributed? Please make it easy, maybe just by logging on to AmigaKit for payment and download. Maybe also offer it on floppy (just a thought there) through AmigaKit.
So, anyhoo, I vote for upfront fee.
BTW, your link is dead…. ;)
-
Thanks, link fixed.
We were thinking of maybe $5 to $10 for each development cycle/major release to cover the ongoing developer costs assuming we have enough interest in it.
The AK-Datatypes package was last updated way back in 2009 before we took over development this year. Our developer has already brought akPNG and akTIFF components up to standard with the latest LibPNG, ZLib. The JPEG datatypes are now being worked on.
Once the hard work of catching up from 10 years ago is done, then smaller, frequent updates will be much easier.
-
Can one expect updates to land on aminet, or will they vanish in the obscurity of AmiStore?
-
I would be okay to have a small charge. Would also be nice to have some updated sound datatypes as well that work with 3.1.4 (WAV, AIFF) but don't think that is part of AK.
-
After a year of development and struggling "in the dark" without any documentation, the datatype.library has been built from the ground upwards. It has been a long journey and hard work but the same developer who created a new sound datatype for us has gone further and created a modern datatype library that can be built upon going forward with some exciting new features.
The collection of AK-Datatypes, datatype.library and sound datatypes for our Classic systems are now progressing to beta test.
-
So it will be called the 'AKdatatypes.library', to not get confused with the systems own datatypes.library?
-
No, it is a replacement and enhancement for the system datatypes library.
-
Include the DTM_WRITE method please do you can convert files
-
commercial model suits me fine, would rather pay for a quality product and support it. :)
-
So AmigaKit are developing their own datatypes.library in parallelle to OS developers extending and improving the official datatypes.library - or is this coordinated so that the above mentioned library is the official one shipping with OS 3.2?
-
@kolla:
No, it is not coordinated with OS3.2.
-
So we are here witnessing fragmentation of AmigaOS development in the hands of commercial vendors - exactly what commercial closed source development was supposed to prevent - right? *slow clap*
So what is this “new” datatypes.library then, did AmigaKit/AEON buy old v45 from Roland Mainz?
I have still not seen any good answer for how AmigaKit legally can just ship old ClassAct gadgets etc with their commercial product like ImageFx... the old ClassAct license specifically says they cannot do this as the distribution license is not transferrable. Did AmigaKit get permission from the old ClassAct team, or from current owners Hyperion?
Does anyone care?
If not, I suggest we just upload updates for all classes, libraries and other OS components to Aminet, for the sake of less fragmentation.
-
@kolla
No, our developer who wrote the enhanced sound datatype from scratch has also spent the last year writing the datatypes.library from scratch too.
It has been very hard work without documentation and a lot of trial and error to get things to work but we are almost there. These new datatype libraries and classes are re-implementations with a future vision on how the current limited datatypes system should grow.
-
I suggest we all create new libraries with various functionality and release them into Aminet under well known names just to have some fun. ;D
-
It has been very hard work without documentation and a lot of trial and error to get things to work but we are almost there. These new datatype libraries and classes are re-implementations with a future vision on how the current limited datatypes system should grow.
Then why don’t you just let “your man in Havana” join the OS team, so he can benefit from documentation, official support etc??
-
Then why don’t you just let “your man in Havana” join the OS team, so he can benefit from documentation, official support etc??
Hello,
There are a few problems with doing that:
1. From what I have read, there seems to be a legal dispute around OS 3.1.4 currently and who knows what will happen to the IP in the future? We prefer not to build our house upon sand.
2. Our developer is a professional coder and doesn't invest months of hard work in Amiga software projects for free. Are any of the OS developers paid for their work?
3. We are paying a lot of money for development and we need the freedom to release our own IP and build upon it regardless of other circumstances.
4. Our developer for this project has not been involved in any OS team in the past and the resultant code has been developed in a "clean room" scenario. We don't want to change this as this could jeopardise the entire project.
All of our developments are conducted through our Amiga Developer Team (http://www.amigadeveloper.com). This was established way back in the ninetees by the original Amiga.org management and we have been for some time continuing this.
-
Then why don’t you just let “your man in Havana” join the OS team, so he can benefit from documentation, official support etc??
1. We prefer not to build our house upon sand.
The house is already in sand, you are merely replacing the door frames.
-
The new datatypes.library is complemented by the new AddDatatypes command.
(http://amigakit.amiga.store/images/datatypes_v46.jpg)
-
Regarding the classact gadgets, I for one am in touch with Osma Ahvenlampi and he doesn't give two fux what anyone does with them these days, he doesn't even have his own copy of the source code any more.
-
If he is not mentioned as (one of the) copyright holder noone gives even one fux who Osma Ahvenlampi is. ;D
-
He was one of the “original” ClassAct team... tau, along with caldi, mitchman...
Caldi apparently cared enough fux to accept payment from Hyperion for this intellectual property, so they are now the owners and the ones who’s fux one should worry about...
What does datatypes v46 offer over the official datatypes then? And how is compatibility with future “official” OS3 releases, or is this the dawn of yet another OS3 “spin”?
Maybe ProDAD could be convinced that they should release pOS again, just for shits and giggles...
-
What does datatypes v46 offer over the official datatypes then? And how is compatibility with future “official” OS3 releases, or is this the dawn of yet another OS3 “spin”?
Our developers are working hard to make sure that it is compatible with legacy versions. However with almost zero documentation, there is a lot of trial and error. Additionally the guidelines that Commodore published back in 1993 have not been adhered to by third-party datatype developers since and this means that our new library needs to be forgiving enough with the many datatypes out there on Aminet.
For the future, we have some interesting plans. If you recall the sound datatype project replacement introduced streaming for the first time to the Amiga. The new project of the datatype library is a foundation for many progressive developments. No one has worked on the datatype system in any meaningful way since the late 90's. It is exciting to plan for the possibilities and follow the path that Commodore would have gone down with the system if they had survived. Watch this space!
-
If you recall the sound datatype project replacement introduced streaming for the first time to the Amiga
I don't know about "first time", wasn't this one of the new things with ProDAD's datatypes in pOS as well? :)
-
Maybe ProDAD could be convinced that they should release pOS again, just for shits and giggles...
What do you mean with 'again'? Afaik there was only the pre-release. These demos run fine but all the libraries and stuff are worthless without an SDK.
-
What do you mean with 'again'?
convinced, again.
Anyways, just an idea - AmigaKit/AEON could possibly have their own operating system by buying pOS from ProDAD (if possible) and build their business on that.
-
What does datatypes v46 offer over the official datatypes then? And how is compatibility with future “official” OS3 releases, or is this the dawn of yet another OS3 “spin”?
Our developers are working hard to make sure that it is compatible with legacy versions. However with almost zero documentation, there is a lot of trial and error. Additionally the guidelines that Commodore published back in 1993 have not been adhered to by third-party datatype developers since and this means that our new library needs to be forgiving enough with the many datatypes out there on Aminet.
For the future, we have some interesting plans. If you recall the sound datatype project replacement introduced streaming for the first time to the Amiga. The new project of the datatype library is a foundation for many progressive developments. No one has worked on the datatype system in any meaningful way since the late 90's. It is exciting to plan for the possibilities and follow the path that Commodore would have gone down with the system if they had survived. Watch this space!
Will the akJPEG Datatype also read the EXIF metadata? Now that would be useful!
-
What do you mean with 'again'?
convinced, again.
Anyways, just an idea - AmigaKit/AEON could possibly have their own operating system by buying pOS from ProDAD (if possible) and build their business on that.
If I was them, I'd buy the sources for Windows 3.0. It already runs on my Amiga2500 with Bridgeboard card. It could be ported to the 68000, imagine the potential! ;D ;D ;D ;D
-
Will the new datatype.library still be compatible with the warp datatypes?
-
Dear Matthew,
2. Our developer is a professional coder and doesn't invest months of hard work in Amiga software projects for free. Are any of the OS developers paid for their work?
while it’s absolutely not mandatory, especially since we are talking about a system with an old tradition of self-taught coding enthusiasts, most developers who invested years of hard work in OS3 have been indeed professional coders with degrees for decades or at least were for extended periods of their career. And not taking money was our own choice, as you know very well.
So what point exactly are you trying to make with that statement? Please note I’m not criticising your programmers for taking money, that’s absolutely legitimate.
Don’t get upset by Kolla, embrace the bear instead. ;)
Best regards,
Marcus
-
@bubub42
I have greatest respect for the good quality work you do, giving up your valuable free time in the process. As professional coders by day, I trust you make this choice with your eyes wide open. I hope that those that collect the significant proceeds of that work with ease take a moment to recognise the immense contribution that volunteers give.
Sadly we have witnessed commercial exploitation of goodwill far too often in the past in this community, unfortunately having witnessed it first hand. We have always endeavoured to re-invest our business income back into the Amiga eco-system, including funding developers.
-
@amigakit
Saying sorry when you wronged someone is much better than a lengthy excuse that says nothing.
-
No, it is a replacement and enhancement for the system datatypes library.
:'(
I have now lost interest in this project. Good luck to you!
-
...and with this project AmigaOS continues to splinter. Good intentions, bad result.
-
Getting closer to the pre-release now.
A few problems showed up in testing using the v46.1 datatypes library: in some datatype descriptors - the built-in function was indicating it could handle the data, yet the pattern was failing. A solution was found by our developer after many days of debugging. We are now working towards v46.2.
-
in some datatype descriptors - the built-in function was indicating it could handle the data, yet the pattern was failing.
Aha, it was probably interference from the tripolymer ionic polarity units that caused the pattern to fail. Classic!
-
pffffuahahahahahaha! :D ;D
-
@amigakit will the new datatype library be made available for OS4 at some point?
-
@remotenemesis
That is a distinct possibility so there will be a unified library for Classic and the X5000, X1000 and A1222 Plus platforms.
-
The developers have been steadily working on the V46 datatype system files to bring them closer to release standard. They have made some great progress recently.
An update to the datatypes.library to v46.2 now fixes some unwanted Enforcer hits and tests so far are positive.
Datatypes library has CPU versions for 68000, 020, 030, 040 and 060.
The AddDatatypes command also gets a version bump to v46.1 with some additional improvements added.
(http://amigakit.amiga.store/images/v46_datatypes.jpg)
-
I asked before, but it must have gotten lost in the clutter.
Is it expected that this new system will be compatible with all classic datatypes, like the 3rd party warp datatypes, or will it require previous datatypes be updated to conform with it? I would assume so, and hope so, but it is never safe to assume.
-
I asked before, but it must have gotten lost in the clutter.
Is it expected that this new system will be compatible with all classic datatypes, like the 3rd party warp datatypes, or will it require previous datatypes be updated to conform with it? I would assume so, and hope so, but it is never safe to assume.
I think that's already been answered as "yes".
I don't really see the point in rewriting datatypes.library. It doesn't really do very much - all the power is in the superclasses, and you can extend and write new ones of those as much as you like without touching datatypes.library. If you want to write a video.datatype you can, without datatypes.library knowing or caring what such a thing is. I wrote a structured art superclass for OS4 so IFF DR2D and SVG (and.. I think that's as far as I got) can be viewed by Multiview. It works, and programs can (in theory) load such objects retaining the original structure and write them as well (can't remember whether I ever implemented this stuff). datatypes.library doesn't care, it just looks at the IDs and passes everything down to the subclass, which it also doesn't know about as it was written years before it existed.
datatypes.library does have shortcomings, but none that actually prevent new formats from being supported, so I don't really see what this gains apart from potentially some slightly better APIs (which nobody will use because they won't work on the version everybody has).
(btw, the animation.datatype is horredous, if anything needs rewriting it's that thing)
-
@chris
I believe animation.datatype has been rewritten for OS 3.1.4.
Anyways, the new feature in *this* datatypes.library and sound.datatype, from what I understand, is ability to present/play a datastream, opposed to current dataype system that won’t process anything until it sees EOF. This was a shortcoming that became very obvious as streaming of mp3s became popular back in the 90ies.
-
@chris
I believe animation.datatype has been rewritten for OS 3.1.4.
That's good to know. Does it fix all the shortcomings though? (the main one being only supporting palette-mapped images)
Anyways, the new feature in *this* datatypes.library and sound.datatype, from what I understand, is ability to present/play a datastream, opposed to current dataype system that won’t process anything until it sees EOF. This was a shortcoming that became very obvious as streaming of mp3s became popular back in the 90ies.
I believe that's present in the updated sound.datatype, and didn't require a new datatypes.library.
It was also possible to stream with the old datatypes.library/sound.datatype, although you could only "play" not capture the data. I thought this worked without it seeing EOF but maybe not.
-
After feedback from beta testers work has continued and our developer has just completed a new version:
(http://amigakit.amiga.store/images/v46.7_datatypes_lib.jpg)
Fixes:
- a fix for allowing the ascii escape code to be allowed when detecting ascii text
- a fix for creating an object directly using the class and not the usual detection route
-
The new AK-Datatypes Prefs have been completed:
(http://amigakit.amiga.store/images/akdatatypes_prefs.png)
-
What datatypes needs is support for stream based i/o, progressive loading/rendering, especially on audio and video/animation formats. It would be great also if every datatype had 'save as native' built in, and MultiView could act as a simple file format converter, like Preview on the mac.
-
Some good development work in the last few weeks on AK-Datatypes: AK-ILBM updated, Picture Datatype updated and Datatypes Library updated in their PPC (V54) and 68K (V46) versions. We are upgrading these ready for the A600GS (https://wiki.amiga.org/a600gs) and also the forthcoming Enhancer Software V2.3 (https://wiki.amiga.org/enhancersoftware)
AK-ILBM Datatype V54.19 / V46.19
AK-DEEP Datatype V54.1 / V46.1
Datatypes Library V54.24 / V46.24
Picture Datatype V54.9 / V46.9
(https://www.a600gs.com/images/amibench_ak-dataypes_a600gs_sm.png) (https://www.a600gs.com/images/AmiBench_AK-Dataypes_A600GS.png)