@SkatemanQuote:
You probably remember wrong, because labeling to MOSSYS: will break things. MorphOS has the MOSSYS: assign which points to the SYS:MorphOS/ directory (MorphOS separates OS files from user files, and OS files reside in this assign). So, relabeling a drive would collide with it.

To avoid confusion I would change the device names of partitions manually to something more explanatory rather than letting OS name them as .1 etc. It's best to do this before or immediatelly after installing the OS, before any applications or configs start pointing with device names (which is a bad practise anyway, but some will do it anyway).


SYS: is always automatically assigned to the partition that system was booted from, so this works correctly always and no need to worry about it, and never try to change it in any case.

I probably would rename device names of MorphOS partitions, for example, to MDH0:, MDH1:, MDH2: etc.

By default the volume name for the system partition is Workbench: on AmigaOS and System: on MorphOS, so this doesn't clash and you can leave them on those names.

Other partitions like Work: can be relabeled as you wish. For example, MOSWork: would work :)

Well.. I combined this with another script I've made earlier, and here's the result: download

Features:
- Creates separate archives of directories from the source dir
- Adds directory icons into the archives if found
- Handles spaces in dir names
- Progress output on the shell
- If there were errors while archiving, it informs on which dirs it happened
- Can be used with DOpus ("Execute S:archive_dirs.script {s} {d}", output to window)

Usage:
- Execute archive_dirs.script SOURCE DEST
- Important: DEST must end to : or /



Hope it doesn't contain much bugs :)

@CagemanQuote:
Heh, yeah, but you got an ugly solution ;) Why to use 3rd party tools when you can do it in OS, and I also think that the solution you got doesn't work when there are spaces in directory names.

@Cageman

This can be done in the Shell quite easily, for example, like this:


This works if you CD into the corresponding dir first, and it creates archives in the same dir. But you could expand this to a better script which would take source and destination directories as arguments.

Hmm.. I don't remember I've changed anything related in the code, on purpose at least, but I'll try to check it... thanks for the report anyway.

@TSK

Quote:
Amiga filesystems (like SFS) have traditionally recommended to use block size of 512, which is basically good for small files and it wastes less space from the disk. But if you want to speed up handling of big files (like media files, archives, etc), then you might want to consider using bigger values... 1024 as a moderate compromise, 2048 for focusing more on the speed, or even 4096.

The bigger the value is, the more it consumes memory (buffers * blocksize bytes for each partition, 500 buffers with 1024 bs would consume 500kB of memory) and more you waste disk space (if you have a 20 bytes config file, it will take 4096 bytes from hd with 4096 bytes block size). So, I wouldn't recommend big block sizes for a boot partition, which contains thousands of small files.

In my opinion buffers have actually bigger impact on speed with many real world operations (like when deleting/scanning files) than the blocksize. So if you don't have that much memory, I would use small blocksize, but at least moderate amount of buffers. IIRC HDToolbox on 3.x had default value of 60 or 80, or something like that under 100, for buffers. IIRC SFS documentation recommended to use 128 buffers or so, and I've felt that it's quite good to have it over 100 or couple hundreds on classics. On NG I personally have raised buffers to 4096 on partitions I have lots of small files and I need to delete large amounts of files regularly, and 2048 on other partitions. It really shows in speed when you delete, for example, a system backup directory.

As said, buffers can be changed easily, but changing the block size will need a re-format of the partition. So it'd be more important to decide the block size before taking a new disk in use.

@Steady

Hmmm... why would disk space affect to memory consumption? Isn't it mostly Buffers * Blocksize in this case? On NG machines people might use buffers as hundreds or even thousands, because memory isn't an issue there, but on classics I'd stay somewhere like 128 or so. And keep blocksize as 512 if there isn't a good reason and memory to make it bigger.

Buffers can be set in HDToolbox or checked (or modified temporarily) by the AddBuffers command.

I once made a file size based counter ;) I don't know if there would be other way, but if you don't have the ForEach command (on OS3, for example), then you could hack it like this (modified it to do what you asked) :P



And that would output:

AHI's mixing routines are quite primitive and if you increase channels, playback quality decreases even if you aren't playing concurrent sounds.

I would advice to set channels as few as you still find comfortable in your use.

I've noticed that I don't use more than two programs that output audio at once pretty much ever, so I've set my channels to two. This still allows me to play something like video clips or test a game while listening music on the background, but keeping the quality quite good.

This is why AHI has the Music Unit, which overrides anything else playing to keep the quality at max in certain cases. But if you want to let everything (including the Music Unit) to play simultanously, you can forward the Music Unit to other unit, but especially in this case I would really keep amount of the channels low.

@AmigaSociety

Or you could use bigger image on PPaint, but then cut out a 256x192 sized brush and save that. Draw a frame for your image or something like that to make cutting easier.

@Skateman

Thanks!

@Skateman

Yes, or actually this has been the case for three years already. I tried to submit my first program for xmas 2017. At first the communication seemed to work and promises were made, but then it faded and it's been harder and harder to get replies, and now nothing for a long time. At one point it was explained that it got under other work, I think it was around the a.org rebuild, or so... This just seems to be too hard and I don't know if I even want them there anymore if offered... what would happen with updates etc? It's just better to look elsewhere now, even though the original idea was to support this ecosystem too and to get at least some compensation for my hard coding work.

@benny

Nope, I've given up with that now. I'll have to think other solutions at some point, but if someone really needs it, please contact me privately.

Ok, thanks. And yes, I posted it first time Jul 30th, and when it didn't appear, but someone else's news item was published after it, I tried to post it again few days later.. maybe a week ago now.

My news item submit(s) about a whole new program I released have vanished somewhere or aren't accepted here for some reason, but I still think that this would interest users at this forum. I've got good feedback with my previous programs here, so I'd like to let you guys know about this one too and would be happy to hear any comments.

RNOPublisher is an easy-to-use PDF publishing program, which has been made with Hollywood.

Features:
- Supports the most common page sizes in portrait and landscape modes
- Freely placeable text boxes, images, PDF links, and graphical objects
- PDF links can point to document pages or web links
- Supports base fonts that don't affect the file size
- Custom TTF fonts can be embedded into documents
- PDF outlines (table of contents) support
- User creatable page templates
- PDF exporting supports passwords and compression options
- Constrained mouse movement and resizing using qualifier keys
- Additional document saving and loading in its own format
- Drag & drop loading of documents, pictures, and text files


(click to enlarge)

Here is an example PDF created with the program, and the program can be downloaded from OS4 Depot or Aminet. It's also available for RTG equipped classic Amigas, but needs a beefy setup.

I've been using:


But AFAIK openurl is 3rd party for OS4 and OS4 comes with URLOpen by default, but maybe it'll work with that too?

Does it work now? I noticed that my own internet radio player program also didn't get the station list from Shoutcast few days ago (it reported connection timed out), but now it does again today. Quick googling told that there were some major server changes going on recently.

@trixie

Quote:
Well, I've reminded them by email and forum pm's several times and once they got reminded live (at Amiga 34), and I've got some replies where they've said they're sorry for the delay and will add the program to the store, but still nothing. Same with my other program, which I'd also like to get to the store. My spoken English is worse than Finnish rally drivers talk, so not going to give a call at least :)


@Amigo1

Quote:
Thanks for telling that, I noticed that I don't get emails about private messages.. hopefully changing the "Notification Method" setting fixes that here.

About MP3 tag editors... yes, the existing tag editors are very much lacking in several ways. Many of them support only v1 tags, but not v2 tags, or if they support v2 tags, then only one version. They also support very limited amount of v2 frames and are designed to edit just the frames their programmer has decided to support. And last but not the least, many of these Amiga libraries/editors are buggy and trashing memory etc. Even standard tag editing functionalities in other operating systems are badly broken. For example, Windows 10 breaks tags if they contain frames it doesn't know.

That's why I decided to write my own MP3 ID3 tag editor. It features:

- Reads v1.0, v1.1, Enhanced (v1+), v2.2.0, v2.3.0, and v2.4.0 tags
- Can write v1.1, v2.3.0, and v2.4.0 tags, and convert between them
- Can remove all kinds of tags
- Recognises all 100+ ID3v2 frames
- Can edit and create 60+ text based ID3v2 frames
- Can attach pictures to MP3 files (multiple images with individual type&description settings), and extract them from MP3 files
- Has a "filename sniffer" to create tags from filenames
- Caches input data of saved files for quick pasting to other files
- Can copy selected frames to other files, or copy data between v1 and v2 tags

The program is already finished, but it's pending to be released at AMIStore for OS4. I already sent it to Matthew over three months ago, but it seems to take time to get anything released at AMIStore, but I'm hoping it'll happen eventually.