)I can compile it fine, but only as an XMMS plugin, and Fink's XMMS doesn't actually have an output plugin for the Mac's sound system. WTF?!Akira wrote:Feel free to move this thread, I don't know if this is the correct forum for it
Anyway, I was wondering if somebody succesfully installed UADE in mac OS X Jaguar? I really want to try it out since it should be the ONLY decent mod player for the Mac, but I know pish all about all that spanner-head compiling shite. Is that Fink (or whatever) tool really needed to make it run? Or could I compile it so it runs on an Xserver? (don't tell me it has no GUI
Any help apreciated!
Lycka till as the swedish would say. You'd better wait for uade 0.90 to appear. It has lots of code restructuring that makes it easier to write GUIs into the uade executable.kyzer wrote: I think it's time to learn Mac programming and make a native GUI for uade :)
I'll make the choice easier for you. Make it crossplatform or I will not integrate it into official uade distribution :) Seriously world has enough single-minded GUIs.mld/ uade team wrote: If you write a GUI, Kyz, consider to use something that might be
crossplatform. :)
How about solving the problem instead of having a work around? Just write the Mac OS X output plugin.mld/ uade team wrote: About the xmms plugin... Just an I idea...
I guess the lack of Core audio output in xmms can be worked around by using Finks ESD/Esound for Gnome and the ESD outputplugin.
It may seem like an asshole thing to demand proper GNU tools, but life without them is not easy. Every version of Mac OS X has become closer to BSD and GNU/Linux systems, I hope the trend still continues ;) Ironically Darwin is a fork from FreeBSD. Where did they loose the good stuff in user space?-)mld/ uade team wrote: Installation steps:
-------------------
1) install SDL and xmms using Fink
2) install poll
3) install gnu libtool using Fink
4) sudo ln -s glibtool libtool (in /sw/bin)
5) rehash (a tcsh thing)
(in uade directory)
6) ./configure; make; make install
No Mac OS X here, although I have had an itch to buy one of those 64-bit dual G5 machines..mld/ uade team wrote: Unfortunately, I can't check it out myself, since I (and I guess
the same is true for Heikki) don't have a Mac here. So you
are on your own.
Ick. XMMS is horrid, the only reason people use it is because of all the plugins. It's the same with Winamp. There has to be someone who will encapsulate the XMMS api and write a proper GUI for it.shd / uade team wrote: Just use XMMS and write proper output plugins for it.
No, it's a BSD operating system. Don't whine because it doesn't have a full complement of SysV calls. If you must complain, complain that it doesn't conform to SUSv2 yet.Oh. btw. Mac OS X is totally b0rken operating system.
http://developer.apple.com/documentatio ... rtingUnix/shd / uade team wrote:Then the compiler is practically b0rken requiring those ugly -no-cpp-precomp switches.
How dare Apple not be 100% compatible with GNU's proprietary extensions! Did you know that portable code means portable to more than one compiler?-no-cpp-precomp uses GNU cpp instead of Apple’s cpp-precomp. Mac OS X uses precompiled headers to accelerate compiling C++ and Objective-C source code. This is done with the Mac OS X preprocessor (cpp-precomp) and not the GNU C preprocessor. Because many open source projects are written with GNU C preprocessor extensions that the Mac OS X preprocessor doesn’t implement, you can use this flag to turn the Mac OS X preprocessor off. If the error messages have anything to do with headers (precompiled or otherwise), this is often a good place to start.
What's so bad in it? It definitely isn't perfect in plugin API, I don't like glib much, and it still has a few bugs. But all in all it does the job pretty well.kyz wrote: Ick. XMMS is horrid, the only reason people use it is because of all the plugins. It's the same with Winamp. There has to be someone who will encapsulate the XMMS api and write a proper GUI for it.
No it isn't a BSD operating system. It doesn't conform to enough many things, where as BSDs do.No, it's a BSD operating system. Don't whine because it doesn't have a full complement of SysV calls. If you must complain, complain that it doesn't conform to SUSv2 yet.
I look forward to seeing it :)I happen to be writing native CoreAudio output for uade as we speak, and have it mostly fink packaged.
Don't bullshit me, it isn't even a language extension. It's an optimization! Apple wanted to have precompiled headers as an optimization, and it broke projects which are valid C. Now GNU people are trying to precompile headers too, we'll see what it brings us.kyz wrote: How dare Apple not be 100% compatible with GNU's proprietary extensions! Did you know that portable code means portable to more than one compiler?
btw. It is an irony that they chose gcc derivative as the compiler for mac os x, and then they broke it. It actually sounds like Apple can't deal with the real world and wants to cause trouble for developers.shd / uade team wrote: Apple wanted to have precompiled headers as an optimization, and it broke projects which are valid C.
Now that's just flaming. It's every hardware and OS creator's perogative to change things to suit themselves. Linux has hurt UNIX development, as there are countless so-called UNIX projects developed which only work on Linux because the authors never tried it on anything else. Then they would notice that other OSes have different system calls, different return codes, different headers, different libraries and so on. There even exists a lot of shells scripts marked "#!/bin/sh", but should really be "#!/bin/bash" because they use bash extensions, and their authors didn't even know that.shd / uade team wrote: btw. It is an irony that they chose gcc derivative as the compiler for mac os x, and then they broke it. It actually sounds like Apple can't deal with the real world and wants to cause trouble for developers.
I didn't set sample_evtime, it seems, so update_audio() looped forever. Well, I didn't know it existed! Why does it belong in an audio driver abstraction, anyway? All the drivers set it to the same value.kyz wrote:And now the CoreAudio driver is working fine, playing the data it is sent, however the UADE emulation always seems to provide nothing but silent data (i.e. audio.c is only ever sending 0 to the PUT_SOUND_ macros). Have you seen that before?
Quite the opposite. GNU/Linux has hugely boosted development and skills for UNIX. You may speculate that *BSD could have become the big thing but it's not totally clear.kyz wrote: Linux has hurt UNIX development, as there are countless so-called UNIX projects developed which only work on Linux because the authors never tried it on anything else.
Actually the only realistic way to do sw devel in hacker style is evolutionary. Those faults will get fixed when there's enough users on each operating system using that software. That has happened to countless projects. We are just one example expanding from GNU/Linux to most widely used UNIX systems (Digital Unix, Solaris, *BSD, ...). Going straight into work-arounding oddities of all UNIXes is over-engineered software design. Better create something workable first and then see what can be done to fit all the code together coherently.Then they would notice that other OSes have different system calls, different return codes, different headers, different libraries and so on. There even exists a lot of shells scripts marked "#!/bin/sh", but should really be "#!/bin/bash" because they use bash extensions, and their authors didn't even know that.
Autoconf wouldn't solve the select/poll problem totally. Yet another #define into headers/code and there would still be more tweaks to code. We just demand poll(). It is found on all modern unixes, so why not MacOSX? Even Solaris has it!This is why autoconf exists. Either you can use autoconf (which, btw, deals with thousands more portability and compatibility issues than you have), or you can continue to flame at each and every difference from gcc+linux that you see. It would also be useful to use automake -- you wouldn't need to waste your development efforts on writing special "--package-prefix" configure options, for example.
Anyway, I replaced SysV's poll() with BSD's select() in 2 minutes -- you only used it once, so there is no need for poll() in your project at all, and no need to flame about the lack of it.
Everything you said in this and other post, please email a copy to heikki.orsila@ee.tut.fi. Then we'll discuss uade development there. I'll bring michael doering & co into discussion.And now the CoreAudio driver is working fine, playing the data it is sent, however the UADE emulation always seems to provide nothing but silent data (i.e. audio.c is only ever sending 0 to the PUT_SOUND_ macros). Have you seen that before?
GNU has, Linux has not. With GNU, programmers would actually read the GNU coding standards. If they followed them, they would be good programmers. I don't see much of that happening with 90% of projects on freshmeat.shd / uade team wrote:GNU/Linux has hugely boosted development and skills for UNIX.
Have you ever heard of this thing called "design"? All the best projects have one of these. Because software has actually been designed with the thought of other operating systems and architectures in mind, and has therefore been designed to be flexible, the actual job of getting the software to work on other platforms is relatively painless.Actually the only realistic way to do sw devel in hacker style is evolutionary.
No, GNU autoconf became popular due to GNU's success. The GNU basic toolset is usually superior to any other UNIX basic toolset. All Linux did was bring UNIX to the commodity desktop PC. Before that, everyone was still using GNU, but they were all big server owners and administrators.autoconf became popular due to GNU/Linux success
You should use autoconf rather than parody it in nonsensical shell scripts. For example, $prefix/doc is the wrong place for documentation on many systems, it should be $prefix/share/doc. Where can I change that? Oh, I can't, your --docprefix option is completely ignored. Great. If you had used autoconf, you wouldn't need to have spent any time manually writing that broken configuration option, and I would have a configuration option that actually worked. If you used automake, which generates makefiles to the GNU coding standards, packagers could just use those de-facto standards to make your code build in a temporary place while having paths hard-coded to their true installation place. But no, you didn't use automake, so you have to spend time manually writing code to let packagers do their job.We have copied ./configure, and --prefix= stuff from there obviously even if we don't touch M4
select() works on N systems, poll() works on N-1 systems. Those systems will never change, but your software can easily change, and in fact I have changed it. Every day you demand poll() is a day your software doesn't work on Mac OS X. Your point again?Autoconf wouldn't solve the select/poll problem totally. Yet another #define into headers/code and there would still be more tweaks to code. We just demand poll(). It is found on all modern unixes, so why not MacOSX? Even Solaris has it!
