I have found that promising library, which seems not yet published online (tell me if you find a link somewhere):
https://www.researchgate.net/project/Fortran-Multimedia-Library
Hello everybody. I am the author of the library demonstrated in that video. The video was intended for a fellow developer of a similar C library to interchange ideas privately, but since I didn’t want to attach it in a mail, I uploaded it to Youtube and sent him a link. I didn’t expect anyone else to notice… and I was wrong. vmagnin actually did found the video, although I never posted any link to it anywhere.
@vmagnin I keep being impressed.
Anyway, this project started a few years ago, and passed several stages. I started it after trying many Multimedia libraries that are available out there. All of them have their pros and cons, but none of them was exactly what I wanted. Even worse, all of them are written in C or C++. I don’t like C and I really dislike C++ because it was meant to be an improved C and did everything wrong in my opinion. So I started my own Multimedia library instead, written 100% in the best programming language ever made, Fortran.
I am using the library on a regular basis myself, but there are some changes I consider imperative for a public release. The library uses custom home-made Fortran 2008 bindings, namely bindings for OpenGL, GLEW (graphics rendering), FreeGLUT (window contexts and text rendering), SOIL (image rendering), and OpenAL, Alut, Alure (sound support). OpenMP is used for parallelization (basically spawning threads, for example sound fade-out is done that way).
This is the underlying structure, and the programmer has full access to it, but it’s normally not necessary. The library provides “higher level” Fortran types to use instead (“classes” in… that other language terminology). For example, one could just use the OpenGL and SOIL bindings included in the library to implement a Fortran program that does animation, but the library provides a “Animated_Sprite” class to use instead, which makes things way easier.
Although the bundle I tried to describe above works well, I am not completely happy with some of the underlying libraries, mainly because they are not flexible enough to support future features I am planning to add in the library. Thus I decided to replace FreeGLUT with the GLFW and FTGL frameworks, and completely remove GLEW as a dependency. I am working on those changes but at a slow pace because the library works as it is for me and because none else was really interested, at least so far.
I also wasn’t aware of this community, which seems a great place to interchange ideas, get/give help, learn new things I was not aware of (such as fpm), or just hangout with fellow Fortraners.
Welcome to the Fortran Discourse!
Pleased to meet you @Pap on the Discourse!
@Pap , welcome to the Discourse and Mega Kudos on your brilliant effort with FML. It’s highly impressive what you have achieved with Fortran 2003 and 2008, there are certain challenges and compiler limitations (long wait times for standard features to appear and longer wait with bug fixes) that have made it rather difficult to conveniently pursue certain Fortran library design options, especially with multimedia and graphics. This has deterred in our experience some powers-that-be from funding such pursuits post 2000.
Fortran 2018 has addressed some of the language inconveniences and challenges with enhanced interoperability with C and a few other goodies; Fortran 202X will offer a few more, and hopefully Fortran 202Y will be path breaking when it comes to authoring libraries in Fortran with facilities for Generics and so forth. And compilers keep getting better. Then there is the tremendous effort by @certik et al. who have created a good modern Community for Fortran with improving ecosystem for Fortran library development. Through all this though, FML will stand out with what it achieved when!
I was waiting for years to finally see submodules supported by compilers without issues, and that’s just a small example for a feature that simplifies things and makes the code easier to read/maintain.
The problem is compilers - at least the compilers “common mortals” have access to. They were and will always be behind what the Fortran committees decide for the next standard. However i am not complaining, this is to be expected. Also, it is not always a bad thing: it forces the programmer to get the most from what he/she has, and that can lead to some useful techniques people wouldn’t otherwise bother to put the time and effort needed to develop.
What I am trying to say is having all the convenience at your hands often makes you lazy, while being somewhat limited makes you creative. I am pretty sure people behind big Fortran projects (much bigger than my humble one) learned a lot of new things just because the compilers they had to deal with were limited. As an example, consider LSODAR: it is the best ODE solver I’ve ever seen, it is used by many others such as Scilab, R, and the Matlab equivalent is suspiciously similar (my educated guess is they just copied LSODAR). And yet the original was written in Fortran 77… I am pretty sure their developers learned a lot of useful techniques, just because they had to.
Made my day.
Cool! Is there performance difference between LSODA and LSODAR? I know LSODAR added root finding stuff. But just curious is there some performance advantage of LSODAR over LSODA? Thanks!
No, there is no performance difference worth mentioning. The “bottleneck” of the solver is the integration, especially around the point(s) the algorithm needs to switch between non-stiff and stiff methods. Root finding is the easy part, and it is not mandatory either: if you don’t need root finding, you can switch it off completely. You don’t have to provide constraint functions; if you omit them, the root finding functionality is just not used.
LSODAR is just an improved version of LSODA with optional extra functionality. So personally, I see no reason to use LSODA.
@Pap, have you published this library?
Hi @Tonamic and welcome to the Fortraners’ community. I’m sure you will find a lot of useful stuff in this discourse - information, software, people willing to help, and interesting discussions.
Yes, I did, back in 2005-2006. It was in my website until recently, available to whomever wanted it (together with other stuff, such as Maxima projects.) However Google wiped out old websites for some reason, including mine. I actually found a warning mail about website deletion, if I don’t respond to their call and somehow migrate the website to their new service (whatever that is.) But I saw that email way too late, since I almost never use my gmail account. So the website is gone. To be honest, I doubt I would bother doing what they asked, even if I saw that email earlier. I do not like Google services, my little website was there only as a quick, “temporary” solution that aged there.
Anyway, I still have the library, of course (and I actually use it often.) It’s just a Fortran module, plus the F77 ODEPACK/SLATEC procedures needed. But it is mostly Fortran 90, not modernized to Fortran 2008 or whatever. Also, documentation is just comments in the code (no FORD, RoboDoc etc.) It definitely needs some work to be modernized - remember, this was written back in 2005-2006.
I didn’t bother to fully modernize the library yet. I guess at some time I will have to do that, but I postponed it because I had other things to do - and it just works as it is anyway. If you really want this old version now, I’ll be glad sharing. I don’t have time to bother making another website right now, I don’t use any “social” media, and I definitely don’t want to use github, However I can temporarily upload it somewhere.
Hi @Pap, many thanks for your kind and helpful response, also for the advice on Google services (which I am using right now and incidentally keep receiving similar messages right now about migration to another service…)
Yes, it would be great if you could share your library. This is for a hobby project which I have started recently (tonamic.com). The main idea is to develop a web-based application, for which we will be using Python as well, but also to keep the current desktop application (mainly using Fortran). I am now considering a few different ways of playing back the generated score in real time, incl. using PortAudio, but I think your library could provide a more straightforward solution.
Although you are not a fan of Google services, you could perhaps share the library via Google Drive? That will be much appreciated.
Definitely fascinating! I hope you will publish the code soon.
I obviously misunderstood what you asked, because the conversation above shifted to discussing ODEPACK for a while, and just before you asked. So I assumed you meant the small library I wrote back in 2005-2006 to facilitate using ODEPACK’s (D)LSODAR. But it seems you were asking about the multimedia library, which was never publicly released and was never in my website as well. I couldn’t write that library in 2005-2006 anyway, since I doubt any Fortran compiler supported Fortran 2003 back then - definitely not the compilers I was using.
FML, the multimedia library, still exists (as a backup) in the form used in the video above. However, I don’t use it anymore in its original form. Some time ago, I decided to split it in two parts: The graphics part (which I call FGL,) and the audio part. FGL has been changed a lot after the split (the underlying C libraries were changed, most object-oriented features are still redesigned, and the classes inheritance tree becomes something very different.) The audio part, on the other, hand hasn’t been changed much.
At any rate, there is no point to release FML anymore, and its two splits are definitely not ready for a release. But as I mentioned in another thread, I am concentrating on completing one part of FGL for now, and release it separately, because that makes sense: It’s the Fortran image library, and it is not far from being good enough for a first fully functioning public release. Although free time needed for that first release is a factor I can’t estimate accurately, I expect this to be done in the next few months, most probably before the end of the year.
Your project, which I find intriguing to say the least, has different goals than mine and I am interested since I am an amateur musician/composer myself (my now-gone website actually had a detailed description of my gear and some sample tunes of mine.)
I’m not sure how exactly the “ethnic” tones I hear in the videos were produced, but they are definitely my thing. I play synthesizers mainly, but almost always focused on ethnic sounds.
Anyway, I am guessing the audio part of my library could be used for playing back the Tonamic generated score, and I don’t think playing back in real time would be an issue. Since I splitted FML in graphics and audio parts, I didn’t really pay much attention to the audio part because I consider it the less challenging of the two. I guess with some polishing it could be ready soon, but I won’t have time for that - not before the Fortran Image library is done and released, at least.
Many thanks for your informative and encouraging feedback. I do look forward to interacting with you more on this topic once your Fortran libraries are ready. Best, Leo
I have recently discovered:
Codeberg is a democratic community-driven, non-profit software development platform operated by Codeberg e.V. and centered around Codeberg.org, a Forgejo-based software forge.
It is based in Berlin and hosted in Europe.
It would be great if you do. Very interesting project.
There are a number of alternatives to GitHub to suite one’s preferences.
Hi!
I found this thread a few months ago as I was interested in developing graphical applications in Fortran. I saw that the code for this fortran multimedia library (FML) was not publicly available, so I have decided to start working on my own and I’d like t share my progress in case some of you are interested in using my code or would like to contribute.
I have already finished developing Fortran 2018 bindings for the latest version of GLFW, v3.4, and I have been working on an extension to the well known glad generator for OpenGL, that is already working, although has not been extensively tested yet, and that I am still improving. The advantage of using glad is that it easily allows generating interfaces for other specifications such as GLES and Vulkan.
This already allows my to handle windows, user inputs and modern graphics. The next logical step will be sound support, and the long-term goal is to build a complete, modern multimedia framework in Fortran.
The code is available on my github:
glf90w: GitHub - AarnoldGad/glf90w: Fortran bindings for GLFW 3.4+.
glad-fortran: GitHub - AarnoldGad/glad-fortran: Fortran generator extension for glad2.
Feedback is of course appreciated.