The ReggCopy example fully works now. I also have ReggCat application, which is a simple file joiner using Reggae and showing a simple form of dynamic object reconnection. Now I work on ReggDown, which is a HTTP file downloader. It is a connection of http.stream with file.output. This example explains how to show downloading progress dynamically (it is very easy, as the download runs on its own thread automatically).

All three programs will be released with full sources as Public Domain. I plan to clean up the documentation and release file.output class with examples and documentation then. This will complete the stage 1 of the bounty.

[ Edited by Krashan 18.06.2012 - 13:10 ]

The stage 1 of the bounty is finished. The bounty archive contains:
- The new file.output class.
- Updated multimedia.class with improvements for handling dynamic port reconnection.
- Autodocs for file.output in AmigaGuide, HTML and plain text.
- Updated Reggae includes for SDK.
- A short tutorial covering examples and installation instruction.
- ReggCopy, an example program using file.output for file copying. Source code included.
- ReggCat, an example program doing file concatenation. Shows dynamic port reconnection. Source code included.
- ReggDown, an example HTTP downloader. Source code included.

Stage 2 of the bounty initiated. It will consists of two classes: audiopcm.encoder, which will convert standard Reggae audio formats to various PCM formats and aiff.muxer for saving audio data in AIFF format. Now working on the first one.

After some break needed for finishing other Reggae classes, I'm back into the bounty. Now I am in the API design stage. I've implemented a MUI custom class which will be provided by Reggae for creating GUIs of encoders, multiplexers and filters (it is derived from MUI Group class). Then I'm adding GUI creation function to the library API of multimedia.class. The next function will be one taking a pointer to the GUI object and building Reggae structure according to selected media formats and then setting attributes to Reggae objects according to what user has selected with the GUI. Then application programmer wanting, for example, to save some audio data to disk will do following steps:

1. Call GUI generation function with appropriate tags saying "generate GUI with selection of all available audio encoders".
2. The function will return a MUI Group object which may be added to MUI application either statically or dynamically.
3. User can now select audio format and then encoder parameters (for example if he selects AIFF, he can then select bits per sample, more advanced encoders will have more settings of course).
4. When user clicks "Save", application calls Reggae structure generator function. It takes the GUI object created above, reads selected format, creates instances of encoder and muxer, sets parameters selected by user, connects and returns a complete Reggae object.
5. Application connects audio data source on input port of returned object, some output class (for example file.output) on output port. Then just calls MMM_Play() method on *.output object. That's all, audio is saved.
6. Reggae object may be disposed now. MUI object has been attached to application, so it will be disposed automatically. Of course the same MUI object may be reused multiple times to save many audio streams.

The second "bounty pack" will contain two documents, one for application programmers and one for class implementors, describing the whole thing in details. Of course example source code will be provided too.

API for generating user interface for selection of Reggae multiplexers and encoders is almost finished and works. For now I have only one multiplexer providing GUI (it is rawaudio.muxer), but I will also provide aiff.muxer as bounty contribution.



The first screenshot shows GUI with List object as the selector. It is bigger, but it is easier to see which formats are available. It may be also noticed that "endian" gadget is disabled because of bits per sample is set to 8. This dependency between codec parameters is provided by the codec itself, application need not to care about.



This is more compact style, may be useful for extended file requester built with MUI Filepanel class. The framework supports localization of all the strings visible in the window, including format names. While it may seem to be not neccesary for encoders (how one translate AIFF or FLAC?), it will be extremely useful for filters.

[ Edited by Krashan 09.08.2012 - 16:02 ]

You are doing a real good job and regularly informing people about the progress is a very nice style. By reading your posts I always get the impression that you know what you have to do and simply just do it. This is very professional approach. Please keep it going like this and keep us informed about your work.

@Connor

Have always admired Krashan for being very organized, reminds me of.. well, me when I manage projects at work. Before we even got the bounty going he was very clear what he would like to do, which itself probably caused the bounty to fill in no time.

Cannot dissagre with that. Krashan is very well organized with bounties he picked up and as a bounty manager at Morphos.pl I'm more than happy with any transfer I'm doing to his bank account :) The only thing I'm fed up with that is the thing that he has no 48h day ;)

[ Edited by pampers 09.08.2012 - 21:13 ]

This time no screenshots. I've finished and tested localization of GUIs provided by Reggae muxers and filters. Of course this "localization engine" uses locale.library and typical *.catalog files. I've prepared Polish translations for aiff.muxer and rawaudio.muxer and tested the GUI succesfully. Now I plan two following steps. At first I have to implement MediaBuildFromGui(), a function receiving the GUI object after user makes his choice. It has to create needed Reggae objects, connect them together and call a method on them, making them to fetch their parameters from the GUI. Secondly, the two mentioned classes have to be completed, to be fully functional.

Seems that I've made the first useful(?) application using Reggae media save API. It is named U1Synth, and is a simple (some may say - primitive) audio synthesizer. What it does? The synthesis part is implemented as a Reggae custom class, so it connects easily with any audio encoder and file.output object. The synthesis engine is very simple. It generates a sine wave at 261.625565 Hz (normalized C note) and imposes a classic ADSR envelope on it. Then the right side of the GUI is generated with Reggae, it lists all currently available encoders (savers) and allows to set their parameters. The "Play" button creates the synthesizer and connects it to audio.output, "Save As..." creates the same synthesizer and then connects it to what MediaBuildFromGui() returns, then adds file.output at the end.



The big thing is, when new audio encoders will be added to Reggae, U1Synth will just support them out of a box. Without me touching its code.

For now I have only rawaudio.muxer working, so I've saved a raw sample, then used DigiBooster 3 to check how it works. DigiBooster can both display and play a sound, and supports loading raw samples. Here is the result (click for full size):

U1Synth now works also with aiff.muxer. Now I plan to write and complete documentation, prepare BountyPack 2 and claim bounty stages 2 and 3. Note that I consider U1Synth as an extra, I plan to release updated Zormanita sample converter as the stage 4. Zormanita will be opensourced too, as well as U1Synth.

That's definitly a milestone for Reggae framework.

What about a FLAC encoder/decoder bounty?

What about a FLAC encoder/decoder bounty?

Will be the next, after current one is finished.

Current status:
aiff.muxer, done with documentation
rawaudio.muxer, done with documentation
audiopcm.encoder, done with documentation
file.output, done, waiting for docs
multimedia.class, updated with documentation
processblock.class, updated (internal class, so no docs)
stream.buffer, a bonus class, with documentation
U1Synth, example, working
tutorial for Reggae saving framework for application programmers - not done
tutorial for Reggae saving framework for class implementors - not done

Hi krashan,

would it be difficult to implement multiple file.output objects (same file, but different parts) connected to a http.stream object?
Or maybe multiple http.stream objs (with same url) connected to one file.output obj!?

So we could have a multipart-downloader!

I wrote a simple downloader program (httpget) using http.stream some years ago, it has the advantage that it sets the filesize to the total size before downloading to prevent disk fragmentation when downloading big files.
I wanted to implement multiparts to it, but never did...

Now with your file.output class, it would be easier to do that;)

@igracki

In fact direct connection won't work. First, it is not possible to have multiple file.output instances writing to one file. This is because every instance creates a process and this process opens the output file in exclusive mode. Then the second (and any further) instance will fail in NewObject(), as it will be unable to open the file for writing.

On the other hand it is perfectly possible to have multiple http.stream instances downloading the same resource. While API of the class does not have specific attributes for accessing particular fragment of a resource, it may be easily done with extra header fields (there is an attribute for it). The http.stream has a set of methods and attributes for getting HTTP header fields from server response and adding additional HTTP fields to a request. Then response may be examined for "Accept-Ranges", and later "Content-Range", also "Range" may be injected in requests. Application should handle 206 and 416 responses. RFC 2616 contains all the details.

So we are able to have multiple http.stream objects asynchronously downloading different chunks of the same file. Then we need a way to push those chunks into a single file.output. It needs three features, one is already implemented, two are not:

1. Ability to dynamically disconnect and connect sources on input port. It is fully supported to issue MMM_Pause() to file.output, connect another input with MediaConnectTagList() and resume operation with MMM_Start().

2. Ability to perform seek in the output file. It is not yet implemented. Without it, we have to write chunks in linear order, so it may happen than some downloading objects will have to wait on other objects. This effectively kills the idea of concurrent downloading. It can be easily implemented with additional attribute.

3. Ability to set the output file size in advance. As you have stated, it decreases fragmentation. This can be done with an attribute, which will read source length and call SetFileSize(). However it is not implemented in the current version.

It should be noted that implementing features 2. and 3. will need some checks. Currently file.output does only sequential writes, so it can write to things like pipes, consoles, remote filesystems and other DOS pseudodevices. Most of them won't handle Seek() or SetFileSize().

Another important thing is effective buffering. When file.output is connected to http.stream and then started, its worker process will pull data from stream synchronously. You can't manipulate the output object until the data block is received and saved.

Then if I was designing a concurrent downloader, I would use only http.stream instances and handle buffering and writing either directly by application or by writing some clever custom Reggae class with many inputs and one output. The second solution would require the above feature 2. and 3. to be implemented in file.output. Such Reggae class will launch a thread for every input and then multiplex buffers and change output position accordingly.

Saver bounty stages 2, 3 and partially 5 finished

The BountyPack2 archive contains following items:

1. audiopcm.encoder and aiff.muxer, binaries and full source code on BSD licence.
2. Updated multimedia.class, processblock.class, file.output.
3. Bonus: rawaudio.muxer binary. Works with audiopcm.encoder.
4. Bonus: stream.buffer, a FIFO buffer for datastreams.
5. Autodocs for all those classes (except of internal processblock.class) in plaintext and AmigaGuide.
6. "savers_api.txt" document describing the API for application programmers and class implementors.
7. Updated system include files for Reggae.
8. Bonus: U1Synth application as an example of using savers API and writing custom private Reggae classes. Binary and full source code on BSD licence.

Note: I do not consider U1Synth as stage 4 of the bounty. I plan to upgrade Zormanita sample converter with savers API and release it with sources. I feel that a sample converter (which will later evolve into audio processor like SoX but with GUI) is much more useful. U1Synth is just a toy . I guess I will also add some more bonuses to the final stage. The final stage will consist of Zormanita, its sources and some tutorial about it.

Then I officially claim 2/3 stages as done and claim 900 PLN of the bounty. I will wait 7 days from today for any comments and remarks here. If there are none I understand there are no objections for my claim and money transfer.

[ Edited by Krashan 23.08.2012 - 15:27 ]

An additional wave.demuxer, able to write 8 and 16 bit WAVE files will be a bonus for the last stage of the bounty. It is already written and tested. Zormanita is fully functional now, including progress reporting. It needs some final touches and extensive comments should be added to the source code. I expect to claim the last stage of the bounty next week.

That is great news. If I weren't so broke this month, I would add more money to the bounty before you claim it. If you are not claiming the bounty before the 1st of Sept. and if I remember this thread after I get my next check, I will send a donation to the bounty for your hard work.

Thanks for moving MorphOS3.x forward with projects like this one.

If you are not claiming the bounty before the 1st of Sept. and if I remember this thread after I get my next check, I will send a donation to the bounty for your hard work.

Maybe you can better utilize your money . As I'm nearly done with all the stages of current bounty, I will set up another one soon. It will be probably bounty for full Free Lossless Audio Codec (FLAC) support in Reggae, so decoding and encoding. Then I also plan a bounty for MUI module for Lua language, so MUI apps can be created in Lua (one of bounty goals will be a possibility of writing private MUI custom classes in Lua). Maybe I will start both of them and take them in order of reaching the money target.

Krashan,
Quote:
How about camd?

How about camd?

I can add it to the competition, anyway starting too many bounties is unfair to donors, as their money is frozen for long period of time. Then I assume I will consider it at least after the FLAC bounty.

The next bounty stage is finished. An audio converter program named Zormanita is released, with source code of course, and a set of updated Reggae classes. Zormanita makes use of the new saver API, so if any new codec is added to Reggae, Zormanita will use it out of a box. It is also worth noting that GUI for codecs is now localized thanks to Christian Rosentreter (German), Antoine Dubourg (French) and me (Polish). The source code contains also some nice tricks like a custom startup code (to make the program shorter ) and opening files by dropping their icons on MUI object inside window. I will write some texts about it to MorphZone Library so the bounty will be completed. What next? FLAC, here I come .