Some components do not have "owners" though so reports will not automatically get noticed unless dev goes looking for them.
But IMHO forum posts can be just as useful.
I noticed that each package on AmiStore has a "bug" icon, which appears to be intended for sending bug reports & requesting product support. I wonder if it might also be the best place for feature requests/suggestions?
amigadeveloper.com appears to require registration, which is a bit onerous IMHO, especially since you say it might not even work as we'd like.
General Amiga forums was what I had initially resorted to, but I was hoping for a better way - perhaps a dedicated sub-forum on a chosen site (e.g. here or AW.net).
And it indeed is a hack! When something entails locking the IntuitionBase, walking the list of open screens, and checking whether the first screen is actually a pubscreen, we can't seriously speak of an Intuition-supported way to open your program on the frontmost screen. Regardless of what the autodoc says - heck, it was written 20 years ago, when you could get away with all sorts of tricks.
That's your opinion. I've been programming on an Amiga for almost 30 years and if there is a function in the SDK like LockIBase(), that indicates to me that the OS4 devs consider it perfectly legal to use.
Besides, you don't need to use LockIBase() and access IntuitionBase directly. LockScreenList() returns a pointer to the first screen in the list which is the front screen according to the IntuitionBase header file comments. It works.
Quote:
What we need is LockPubScreen() supporting a FRONTMOST parameter. Let the system do the dirty work, not the programmer.
If you add a parameter to LockPubScreen() then current programs that use a single parameter will likely fail. It would be better to add a LockPubScreenTags() which would allow future expansion of LockPubScreen() functionality.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
And it indeed is a hack! When something entails locking the IntuitionBase, walking the list of open screens, and checking whether the first screen is actually a pubscreen, we can't seriously speak of an Intuition-supported way to open your program on the frontmost screen.
That's hardly the only example in AmigaOS where you need to do some rather low-level stuff to achieve a seemingly simple high-level result.
AmigaDOS is particularly prone to this kind of issue, e.g. reading hard/soft links, or anything where you need to know about multi-assigments (such as reliably working-out the actual physical path), or asynchronous I/O. Even something as simple as checking the existence of a path is actually incredibly tricky to have work reliably in all cases (such as with handler-based devices).
I noticed that each package on AmiStore has a "bug" icon, which appears to be intended for sending bug reports & requesting product support. I wonder if it might also be the best place for feature requests/suggestions?
Definitly not, I've no idea where the reports via amistre go, but I've yet to see one.
Quote:
amigadeveloper.com appears to require registration, which is a bit onerous IMHO, especially since you say it might not even work as we'd like.
Really? It's no more hard than registering here, and without registration it would fill up with spam adverts for fakes wtches and worse...
And I only meant that you shouldn't expect an instance reponse, once entered into mantis the bug is recorded, but you might have to wait for a developer to have time to do a sweep for projects thet they are interested in.
There is also a forum I *think* there is user section to that, though manly used by devs some of the beta testers at the moment.
Quote:
General Amiga forums was what I had initially resorted to, but I was hoping for a better way - perhaps a dedicated sub-forum on a chosen site (e.g. here or AW.net).
Rather than angsting about where to post it, could you please just posted here, now? That way other users can also give input on how desirable it is, I could even implement is as I was only just fixing up a couple of thins in TuneNet.
A dedicated subforum is barely more useful than a dedicated thread IMHO...
If you add a parameter to LockPubScreen() then current programs that use a single parameter will likely fail. It would be better to add a LockPubScreenTags() which would allow future expansion of LockPubScreen() functionality.
Doesn't need s eprate paramter, just a specific value for the string, either a name "Frontmost" of a defined value that is never going to be valid pointer FRONTMOST= -1
You are right to say that you are allowed to use LockIBase() etc (though with restrictions) but trixies point is also valid, there is a general trend away from low level stuff that accesses system structures, just because it was valid 30years ago, does not mean it will/must always be valid.
trixies point is also valid, there is a general trend away from low level stuff that accesses system structures, just because it was valid 30years ago, does not mean it will/must always be valid.
That is exactly the point I was making. We need to strive for generally safer and foolproof system APIs, and one of the ways to achieve that is to do the low level stuff in the OS rather than in the application. So if opening on the frontmost screen requires locking the library base and all sorts of checking before you arrive at a valid pubscreen pointer, why not let Intuition do it? Having to write your own code that must adhere to all sorts of restrictions is naturally prone to errors, especially as we're talking less experienced programmers.
Rather than angsting about where to post it, could you please just posted here, now? That way other users can also give input on how desirable it is, I could even implement is as I was only just fixing up a couple of thins in TuneNet.
Sorry, I didn't realise you were even responsible for TuneNet's update. My suggestion (which I have already sent via the "bug" icon - apparently to "A-EON Technology Ltd") is:
I would like TuneNet to remember the last track I had playing, so that when I restart TuneNet I can resume from roughly where I was last time. This would seem to be easy to implement, since the current playlist is already stored in tn_deflist.m3u , so "all" you'd need to do is store the line number of the current track. Ideally it would update the stored track number each time it changed tracks (rather than just at exit), so that an OS crash does not cause progress to be lost.
I've been idly thinking about writing my own music player, just so I can have this feature!
Other suggestions, most of which I've previously made:
* The "Internet Radio" folder should be inside the "Playlists" folder, and then "Open Playlist" should default to opening the "Playlists" folder. Rather more user-friendly than simply showing PROGDIR: I think (even if that's what WinAmp also does).
* It would be REALLY handy if the whole path of each music file was shown in the Playlist list, as then I could sort it via path & see everything logically arranged in folder order.
* It would also be rather handy if the track's whole path was shown in the "Info Window", so that I can easily locate where the current track is stored.
* Is there any chance of TuneNet not using AHI in "exclusive mode"? It stops YouTube videos from playing sound in Odyssey, if I have TuneNet open. (Hmmm, or is that what "AHI User Mode" does??? I never noted that before, it really should be the default if it is.)
That is exactly the point I was making. We need to strive for generally safer and foolproof system APIs, and one of the ways to achieve that is to do the low level stuff in the OS rather than in the application. So if opening on the frontmost screen requires locking the library base and all sorts of checking before you arrive at a valid pubscreen pointer, why not let Intuition do it? Having to write your own code that must adhere to all sorts of restrictions is naturally prone to errors, especially as we're talking less experienced programmers.
That's exactly what I have wanted to say quite some time in public and to Hyperion. Higher level API is needed instead of this 30 years old low level stuff. One example is timer.device. You have to play with those struct IO messages and GetMsg loops and so on. Some kind of a class around it is needed. There's a library on os4depot which takes care of that. I haven't used that library in my projects yet but it looks promising and right step forward.
Hyperion should concentrate to improve stability and reliability of the OS and make it easier for third party software developers instead of promising too big dreams like Gallium and multicore which seems they don't have enough resources to get done. Small steps at the time with little resources.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Sorry, I didn't realise you were even responsible for TuneNet's update. My suggestion (which I have already sent via the "bug" icon - apparently to "A-EON Technology Ltd") is:
I'm not exclusively resonsible for it, zzd10h has also done some work, I've mainly worked on adding the ARexx, localising, fine tuning the relay out of the GUI and afew bug fixes here and there.
Quote:
I would like TuneNet to remember the last track I had playing, so that when I restart TuneNet I can resume from roughly where I was last time. This would seem to be easy to implement, since the current playlist is already stored in tn_deflist.m3u , so "all" you'd need to do is store the line number of the current track. Ideally it would update the stored track number each time it changed tracks (rather than just at exit), so that an OS crash does not cause progress to be lost.
That sounds very familar, my fisrt thought was that already works but it doesn't seem to on testing, so maybe I've just seen this request before....
I'll add it to mantis now to reduce the chnace of it being overlooked.
Quote:
I've been idly thinking about writing my own music player, just so I can have this feature!
Well as a stop gap you could write an ARExx script for TuneNet instead..... bit less work and tests out the ARExx interface, feel free to ask any questions.
In fact I wonder if the best way to implment this might be via ARexx, but it would need start and exit scripts to be added.
Quote:
Other suggestions, most of which I've previously made:
* The "Internet Radio" folder should be inside the "Playlists" folder, and then "Open Playlist" should default to opening the "Playlists" folder. Rather more user-friendly than simply showing PROGDIR: I think (even if that's what WinAmp also does).
Internet radio is just another sorth of playlist, you can organise your folders how you like, perhaps what is needed is a playlists directory option in the settings along with the Media directory
Quote:
* It would be REALLY handy if the whole path of each music file was shown in the Playlist list, as then I could sort it via path & see everything logically arranged in folder order.
Doable as an option I think.
Quote:
* It would also be rather handy if the track's whole path was shown in the "Info Window", so that I can easily locate where the current track is stored.
Yes, and I also want to add 'track number' to the ID3 info there.
Quote:
* Is there any chance of TuneNet not using AHI in "exclusive mode"? It stops YouTube videos from playing sound in Odyssey, if I have TuneNet open. (Hmmm, or is that what "AHI User Mode" does??? I never noted that before, it really should be the default if it is.)
This already works that way, in fact User Mode is the mode that locks AHI, you should choose an AHI Audio device number for sharing AHI, that's what the device.audio is for.
Or is that the other way round hmmm need to check up which is which
[edit] Yes choose AHI Audio 0 (1 2 or 3) and TuneNet should share AHI , I could just play the boot sound in MVer at the same time as playing music in TuneNet.
OR in AHI User Mode shoose one of the "Unit 0" modes if you see them. Effectively the same thing from a low level route.
If you are having problems then verify that the *other* prgram is not locking AHI itself. For example HD-Rec will and so will Audio-Evolution they require complete control of AHI to work.
That sounds very familar, my fisrt thought was that already works but it doesn't seem to on testing, so maybe I've just seen this request before....
I'll add it to mantis now to reduce the chnace of it being overlooked.
THis *is* implemented but appears not to be working, not sure why. I know it was before, I remeber fixing a crash realated to it, glad I'm not going mad, something seems to have broke it again.
That is exactly the point I was making. We need to strive for generally safer and foolproof system APIs, and one of the ways to achieve that is to do the low level stuff in the OS rather than in the application. So if opening on the frontmost screen requires locking the library base and all sorts of checking before you arrive at a valid pubscreen pointer, why not let Intuition do it? Having to write your own code that must adhere to all sorts of restrictions is naturally prone to errors, especially as we're talking less experienced programmers.
I don't disagree with that; we do need better API's. I just think that calling it a "hack" is an insult to programmers who are forced to use low-level methods to add useful and sometimes necessary features to a program. I use a lot of screens on my Amiga and find it extremely irritating when a commodity or program opens on the Workbench screen behind the screen I'm working on.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
* It would be REALLY handy if the whole path of each music file was shown in the Playlist list, as then I could sort it via path & see everything logically arranged in folder order.
After reviewing how TN works I've decided against this for the moment, the reason being as you play the tunes the path name is replaced with the TuneName.
If you want to sort / analyse the playlist by full path of files it would be better to use the ARexx interface. I might write an example script on how to do that once I have some more spare time.
Quote:
* It would also be rather handy if the track's whole path was shown in the "Info Window", so that I can easily locate where the current track is stored
I have added the ful path to the Tune Info Window, along with the CD track number, which is something I was missing.
Comments don't seem to display at the moment with any of the files I have, nor copyright even though they are spoosedly set by lame in most of my files.
Does anyone ever see any useful info in the "Notes" or Copyright fields, would be interested in a sample file that "works" if there is one, so I can compare.
After reviewing how TN works I've decided against this for the moment, the reason being as you play the tunes the path name is replaced with the TuneName.
Ah, yeah, this behaviour really annoys me, because it makes it almost impossible to RELIABLY filter (Find) the playlist to only show tracks with a particular filename (e.g. tracks from an album or TV series).
I think this was another reason I wanted the full path shown in the Playlist. It could be an a separate column (the last one since it is likely to be quite long). This would also allow filtering upon the whole path, which would mean I could easily just show tracks within a particular folder (i.e. artist or album or whatever classification system I use).
At the moment it feels like TuneNet is snatching defeat from the jaws of victory, as far as the usefuless of the Find function goes :(
Quote:
Does anyone ever see any useful info in the "Notes" or Copyright fields
If by "Notes" you mean the Comments field, then certainly there is sometimes useful info put in the Comments field of tracks.
Does anyone ever see any useful info in the "Notes" or Copyright fields, would be interested in a sample file that "works" if there is one, so I can compare.
I don't know about "useful" but ADRipper (at OS4Depot) puts "Ripped&encoded by ADRipper" in the MP3 comment that is displayed when you load an ADRipper encoded MP3 file into AmigaAMP.
Just rip a CD with ADRipper, load one of the tracks in AmigaAMP and select Project/Info in AmigaAMP.
I would guess that any commercially sold MP3 would have a copyright in the appropriate field.
EDIT: Tunenet also shows "Ripped&encoded by ADRipper" in the notes when you click the Tunenet Info button.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Sorry my usage of the word "useful" there confused the question I was asking. What I wanted to know was if anyone saw anythin in the Notes ( which is where the ID3 comments should appear) at all?
Anyway reading the spec and examining my mp3s in hex editor and study tunenets ID3 decoder I see whats going on.
The ID3 COMM block has three sections a language descriptor that TuneNet correctly skips, then a "comment descrption" and a "comment body" seperated by a null byte. TuneNet is only picking up the first part as it uses strvcpy() but lame only populates the second part, thus TuneNet doesn't display it.
Based on xenics comment I presume ADRipper must put it's comment in the first part (which is incorrect according to spec). (it probaly ought to add a TSSE block instead with the encoder info though, might always do both I suppose)
So anyway fixable with a bit a string wrangling now I know whats going on (and a memcpy rather than strncpy I expect).
Based on xenics comment I presume ADRipper must put it's comment in the first part (which is incorrect according to spec).
ADRipper (more precisely: its external MP3 encoding module) uses Lame library's id3tag_set_comment() function to insert the comment - I've checked, it's a single-line call. So if the resulting metadata somehow breaks the specification, it should be reported to the library maintainers.
@broadblues To correctly answer your earlier question, the answer is Yes, I do sometimes see something useful in the Notes part of the Info Window.
For example, MP3s of game music downloaded from a Humble Bundle tend to mention the URL of the original band/artist.
Quote:
TuneNet is only picking up the first part as it uses strvcpy() but lame only populates the second part, thus TuneNet doesn't display it.
Since the above info is shown, it seems that some MP3s are wrongly encoded. In which case TuneNet should first try to show the Comment from the correct part, but if it is empty then it could try showing the Comment from the incorrect part.
Hmm okay perhaps in that case an ID3v1 block is being written, not ID3v2 as it seems unlikely that lame wouldn't be using it's own functions. The ID3v1 tags are simpler and not affected by this issue.
Since the above info is shown, it seems that some MP3s are wrongly encoded. In which case TuneNet should first try to show the Comment from the correct part, but if it is empty then it could try showing the Comment from the incorrect part.
Tunenet should be showing both parts, when present.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
