Hmmm, OK - I've installed the latest SDK and I'm just fixing up some compile errors. If all goes to plan I should have a version to download later on this evening.
I'll release it on the TuneNet home page for anyone that wants to try it out. It might not be 100% stable as I was half way through some new code as a replacement to the (p)threads library, and not everything had been fully completed.
There are some minor fixes that were completed though, like the docky issues with OS4.1.
- Edit -> Compiled and working without the need of the threads.library now... but I must have broken the docky somewhere along the line as it's not working.... Looking into it now...
- Edit -> Compiled and working without the need of the threads.library now... but I must have broken the docky somewhere along the line as it's not working.... Looking into it now...
I vaguely recall somebody mentioning this problem when the new SDK was released. Incorrect version number in one of the header files? Compare the new application.library headers to the old ones and you should see the problem.
LOL! I spent a good hour figuring the problem out myself, changed the header version number back to ((uint32)((( 50 )<<16)|( 49 ))) ..and it started working again! ..I was just going to ask here if I was missing an OS4.1 update or seperate Amidock update and I noticed your reply.
Welcome back & take your time, it's not like TuneNet quit working. It works just fine with the old lib for now, so don't rush the change over. Release the new version when you feel its working right.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
Hiya! Well it's *almost* ready to release. I've two potential task deadlocks to fix and 1 small function to address. It won't be tonight, but will be over this bank holiday weekend.
*Update* > I've one last task within TuneNet that uses the pthread API now, so it's not really worth me using pthreads at all! I'm currently in the process of replacing it.
this seems to be the place to get beans attention, so i will post this here:
i just tried to load a DTM (Digital Tracker) tune into tunenet. but there's another format that also uses the dtm extension, and it's picked up by the adlib plugin instead, and that makes tunenet lock up.
do you have a sollution to this problem other than to disable the adlib plugin when playing these kind of mods?
i have seen similiar clashes with other formats.
Some kind of prefs system... or ... i dunno, filetype recognition would be cool. Where you select which plugin that should play which format. If you have two plugins that supports the same format. How is it selected now? Or preferably both a prefs system and filetype recognition, based on headers.
Hey up, I didn't mean to hijack this (p)thread! (excuse the pun...).
Anyway, thanks for all your greetings, my Amiga's getting some use again which is good. Hi Curty, good to see you here! .. and Kicko, I haven't yet finished going through my games collection yet Hi SpotUp, if I remember correctly I put a method in place for a plugin to only pick up playback rights as a last resort; if no other player has picked up the duty (like in Chris' datatypes plugin). It sounds to me like the plugin that is crashing needs some additional code to identify the formats it can play a little better, so to ignore the format/version that is causing the crash, and/or for it to switch to the passive mode to only pick up playback if the other plugin hasn't picked it up 1st. Perhaps a "user" priority should be available within the plugin list.....
Anyway, seeing as people are after some news I can confirm I've totally removed the reliance on pthreads (now uses my own process implementation). I'll be testing this week and clearing down some minor issues and will keep you updated.
Thanks for the responses again.
Oh and Mikey, I'll try and pop up to the next meeting.