I'm often thinking about a tracker project, or a project that includes a tracker. But I've got no platform preference, or to be honest, I don't know what's the right choice and I think asking other people in a neutral way would be a good idea.

Just my thoughts, I should explain them, there's a reason for doing the poll.

​I'm currently using Windows since a few years, sometimes I install a Linux-PC or once or twice a Hackintosh. Couldn't really afford a real mac. But I like Swift. It's 25 years newer than C++ and this would be visible in a Swift-only code base very much. Xcode is pleasant, too. Today I've thought about - at first - how much I would dislike Swift not having an ordered map or in general a red-black binary tree for storing piano-roll-notes or tracker-cells. <map> looks very right for this at first, complexity is on (almost?) every operation something like log n, and hey, C++ is cool for offering this. Swift provides more like libraries from users, nothing that I'd immediately install.

Then my mind kind of turned around and I thought, wtf, actually I'd like to do everything that I do on notes (cells) also on samples. And what would I use for sample buffers? Plain arrays. So, arrays are just enough. I need them to be operated on fast enough anyway. Computers are so fast today, I'd need tens of thousands of notes to notice slow code on notes, so, it's still no point for C++.

​Another thing is mult-ithreading. I liked Windows for providing WaitForMultipleObjects. But it's a bit hard to re-implement fully on other platforms because it can wait on file operations or whatever, too, but that's no the best reason, I don't need to wait for files or network. The other tools you can find seem just to be not tested enough (I guess channels in Golang and Rust are the best.) I've tried several re-implementations of this Windows-design which would rely on pthreads or <threads>, they added race conditions to a test project. I'm not sure I could ever port that thing to macOS without rethinking a big part of the software, though, not that big.

On the other hand, Apple has GCD, Grand Central Dispatch. It seemingly has two Windows-based implementations, I'd really trust them, GCD looks like a fresh concept, probably nothing missing, and porting (using a ported libdispatch/GDC) that to Windows should be easier.

When you look at Rust, the tooling isn't that matured, IDE etc, it has no native environment, when testing to use it for something I hit a barrier of foreign function interfaces (windowing,opengl,portaudio,midi) very fast. With Disk IO it's more like that it's platform indenpendend, but their use of builder pattern looks ugly as can be.

Golang, slow due to "non-zero-overhead" bounds checking, no SIMD. Ponylang? A bit too new, no SIMD either, though promising. Java? Uh. How got Bitwig around the GC that is said to sometimes pause the world like 100ms? They do Java & C++. I'm one guy with limited knowledge, won't try that combination. What's really left? The "native" standards C++ on Windows, Swift on macOS. Swift isn't perfect, even that UnsafePointer thing, missing ordered <map>, NextStep stuff, all looks bad. But it's 25 years newer! You can use nested functions, named arguments (ok, Intellisense can help you on C++ too) and what not.

Swift rocks. Porting from Apple to Windows seems even more doable than the way around. At all, I'm just about to try to write my own personal, xrns-compatible song tool, whatever it is, it may be usable in 2025. Actually my idea has always been a black box that would convert from piano roll notes in one view to tracker cells in another view. I don't believe in a mixture of both views (mixed = piano roll + tracker in only one view). Even if a mixture is possible, it could be added to a "black box converter" solution.

Anyways, it's the "right" time in operating systems history to be stuck on the idea. Windows 10 keeps on nagging me with Edge and weird new stuff. I'll go on reading on Swift and Hackintosh topics the next days. Thanks for the poll answers! (so far)

Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

Normal Members

1100 posts

Gender:Male

Location:Meist völlig betrunken in der Hofnarrenkammer

Interests:Lavalampen stundenlang anglotzen

Posted 27 September 2017 - 22:10

IDK but the OS platform on which is developed is probably not so much important as asking other questions first. Each element will impose its own set of arguments toward the choice of platform, or general tools which is maybe even more important than on what platform they are running.

Just some example as of not to spam the thread too much.

Will the software need to be very portable? What platforms are you targetting? This will narrow the choice of languages useable...it is better I think to have portability in mind from the very start of the project as compared to trying to add other platform support into a codebase that hasn't been built with portability in mind. Mobile platforms might narrow it even more.

What level are you working at? I mean is it a pure hobbyist enthusiast thing, or going to aim for matching industry standards, beginner or experienced in software development? Will you be opensourcing stuff or keeping it private, or are you planning to sell with closed source? Do you have a budget, or do you want to use stuff available for free? Do you plan to code everything, including core functions, yourself, or do you want the most complete set of libraries that will make your task easier and going faster? Don't underestimate the library thing, I guess many noobs have some pride in wanting to have the whole thing flowing out of their own hands being their complete intellectual property, but vastly underestimate the amount of work required to do so, even for projects with little complexity.

What nature should the software have? More loosely developed quickly or a solid tower to build and prevail? More of a simple interface tool, or are you planning to use heavy dsp processing that would require optimisations and a compiled language? What coding styles do you prefer, how do you prefer to design human interfaces? Will it be a one-man-show, or are you thinking about collaborations with other developers, maybe from the start, or maybe in the future?

I mean if you plan to just get going quickly and without budget, learn stuff while you roll, and don't mind a little rough tools, I'd say install a linux distro with complete enough repositories of dev packages and libs, and find which tools suit you. But if you aim to make commercial software, this might be not really the best option.... Then there's ways in between leaving things open for you to decide at later stages...like using libs like JUCE that can be licensed so you don't have to gpl your result, and trying to stay with MIT or similar licenses for other parts that might be of importance as of not to waste too much time on some generic basic or specialized functionality.

And when all those questions are answered, pointing into some directions, there still are big wars of opinions between multiple options for each task - and you have to decide based on further aspects of the project, or just dive into some option to see how it will be going.

Thanks OopsFly for this very inspring, honest, mindful and knowledge based post!

I've forgot to even think (and talk) about these points.

One useless anecdote of my life first. Sytrus was always one of my favourite synths and it kept crashing under certain circumstances. I debugged around and found out that actually something in JUCE crashed. Image-Line used JUCE for some sort of preset management. Anyways, in the end, what was to find out, was that Sytrus set the x86 floating point register at precision to 53 bit or something. JUCE had a float->int conversion hack in it that expected this not to have happened. I mailed the JUCE author that thing, and actually, in the end - also looking at many callback mechanisms - I can say, I want to play safe and "plain, easy" more than JUCE does. I think I should probably get to know JUCE more, I've no idea what it has included now. But to be honest, it didn't meet my felt standard to 100%, more like 99% or a bit below.

Type: Open source

License: even more free than GPL, even more free than MIT, a license with a lot good will and very compatible. But to be honest, the most important thing is imo, I'll never in my life try to break any rule or license, and at the same I'll never engage in a court action or anything because my own rights could have been violated. I'm a pacifist guy with ideals who wants to make music. Though, I think, GPL can limit certain peoples freedom to motivate themselfes, so it may be not the best option, but the mind fullness and community-driven aspect of GPL is still great. There is a good chance that at first above all my own code lines I would write "public domain, do what you want with it" or something better in that sense.

Platforms: The best available combination, e.g. the most used, but also the best to develop. The point is, Windows is used more, but to get a good code base - even though there is virtually no good Swift compiler for Windows yet - Swift seems so ideal. I don't want the shared_ptr boilerplate code and friends later pointing out what pointers actually could be unique_ptrs and the header boiler plate. Even though I can handle it, I think it's a bit wrong to encourage others to use C++ when real alternatives exist. EDIT: No mobile, a desktop is something that I need for music in my case.

Development-type, team-work: actually I've currently got an idea about a mind-map-driven visual development tool (maybe browser based) to have a good foundation how to get collaborative, very easy way to get a collaborated sound software. Or I just should learn GIT, because Linus Torvalds has created it and it's so wide-spread.

Money: forget about money. EDIT: Ok, I think that I buy my computer, so buying something like Intel Performance Primitives, or even licensing a sound "stretching" library like zplane(?), dirac(?), isn't completely ruled out, but honestly I'm not only quite poor, I've also adapted to a life on basics, and with Renoise in mind, I actually feel very good without zplane, dirac, melodyne, mp3. Maybe I should admit that I make my way around wanting these in the first place. Still, Renoise actually didn't add much more than mpReverb, I think. Maybe the convoluter or so? Keep me informed, please If nothing like plugin-support could add good enough DSP to my the project, I think accepting a full GPLed project as best freedom choice as of today might be the best option.

Nature: A very solid "tower", loose kinds of dependencies, though, I think that monoglot development is better than thinking about FFIs and "to what side goes that code". That is why I ruled out the language-combinations, and I'll also go on hating Lua in Renoise. I know about the polyglot approaches, I think that it's actually mostly things which don't fit together. Still thinking about C++ and Swift.

Another idea for you: use a browser engine like webkit for the gui! Nowadays it is highly optimized stuff with hardware acceleration etc. Then do the whole gui in html5/css plus the engine is developed for free.

Yep - improving all the time, so not a bad idea. Also, .js development tools has improved vastly in the last few years.

There's also this article - strangely not mentioning the HTML option: Edit: it does, he's not too impressed though

There could be a way where you use a Browser and let it do all GUI, have it control a "service" written in C++ that would listen and reply on websockets, webrtc or so. But actually, that seems not to offer any bandwidth for seening much of a sound visualization and seems not to be able to be communication channels for all threads and things there could be?

Webkit or a rendering engine itself I don't yet know. I've peeked into chromium and firefox itself, seeing too much code that I don't want. So, if webkit is actually having libcairo, freetype and something glueish that can render html, yep, should try it. But it could offer too much. When something offers too much, you got that code lying there and - at least - my brain could go like "uuuuh". Procrastination

I took some weird legal hemp medicine, I think I might write in a weird way.

Followed the link danoise posted, I think the funny picture at the bottom of the site explains it well. Roll your own thing, because actually the GUI is already that thing where you want to make a difference. Finding something that has that difference in it that I would like to have in a music software, is not likely. E.g. I want dockable windows that can be fixed to some positions in some ways. Windows itself offers nothing like that, they do offer a lot for docking, but I'm not sure I'll get what I have in mind. So..tried to create dockable rectangles in Lua. Better this than 100000 great functions to learn from Windows, Gtk, X11, Qt. Dunno. Ouch.

Just sayin, I've managed to create a start of a mind-map consisting of the current main concept. It's here https://mind42.com/p...65-a71937a725ec and who likes is kindly welcomed to provide any form of feedback they wish inside the mindmap, the collab is the main idea actually. I'll stop posting here - except for desperately asking things in other threads that lead to only the idea of new software. I think, it's nice that Renoise HQ allowed me to ask this question here and I wish you would - when my mind-map has progressed in the future - see and use everything you like of it for and in explicit favor to Renoise, a full backflux to my one and favourite all-time music tool, so, I really want to help and hope you don't frown that I create plans for not yet existent software.

PS: For the mind-map collab one unfortunately needs to get a "log-in", so, feel free to do send me a pm if you like, or fork it in any way. Whatever I create myself shall be public domain & free.

Why websockets if using a browser engine? No need for networking, either communicate with javascript or maybe even directly?

I thought, the networking could help when you would want to use the browser as-is which would have a Javascript-debugger without adding anything to that part at first.

PS: I can only say this for Lua and a bit for python maybe, not knowing Javascript: The interface may be not good enough. E.g. in Lua lightweight objects mean that you either handle them in the C++ Lua side as opauque unknown objects or know/modify Lua. In the Lua side respectively you will (forever) not access bits and bytes from the C++ side very directly, only via the api, which is more code and calls. Correct me if I'm wrong, but there will be glue code for the lifetime of the project, and it's not clear what it could make you have to do. PS2: Just adding: That networking idea or most probably any form of communication isn't better of course. The monoglot approach is my favourite (except e.g. for Golang (current favourite language): adding SIMD code that may be C++, the portaudio wrapper etc, but nothing else).

(PS3: Btw sorry I think mixed up the term lightweight. Afair: The lua-native (not the lightweigt) objects are - actually Lua's handling is - only a bit "kind of opaque" to C++ as long as you don't know Lua well. On the other hand: The lightweight objects (handles) are (by definition in Lua docs) what is opaque to the Lua code, that should be much more correct to say. Sorry. So.. is this or Javascript going to be fast? I have no clue, which is the (my) problem. Roughly: Compiled = fast, few code. Interfaces: Needs to be reasoned about forever to be fast. That is why I don't like "scripting", even if it serves the 50%+ main purpose of everything. IMO, e.g. using Love2d (LuaJIT) to create a game is perfecly fine, because games fit better. Javascript in Browser: Same thing, scripting is essential and gets a share of the whole amount of work. It will cost something. That's why I think I now love Golang.)

I voted linux, of course I'm biased (Arch linux user, reformed gentoo head). Take a look at the repos, and admire the fact almost everything you need is there. I used windows many years ago (10 for precision), and was increasingly depressed by the none-standard nature of the languages available, the hacks required to get things working, and the perpetual cash register for tools (decent debugger, that'll cost you; disassembly tools, that'll cost you etc....). To be fair apple mac is in all probability not a bad choice, it's built on standards compliant foundations, and has a sensible software updater/manager, oh and it's relatively secure. However it would not surprise me if the cash register starts appearing when you need to do something none-trivial.

All of these are in the repos as standard, no hair pulling while trying to setup MSYS, MinGW, or some other foo chicanery. One click, and done.

Maybe it was visible in my mind-map today, I went from Go 64-bit (Windows) to "cgo" because of Portaudio - still thinking "how nice all those Go libraries" - then ran into only problems with MSYS and MingW, the last one being that I was not sure how to tell MSYS2 to use the same GCC that cgo uses (wouldn't be a bad idea when it later tries to use that portaudio library?). I've once succesfully used the DLL features Go offers, but I think that staticly linked GCC stuff on Windows is really painful. Made me abandon Go totally, for dynamic things LuaJIT is just as nice if not nicer.

So, in 2025 we might already have had to look for another solar system, and if we don't come together as a population, it may be Windows based? As I understand you it is important to have Renoise installed and make music with it, also none of the operating systems can be left out, even if only one seems to shine.

Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

Normal Members

1100 posts

Gender:Male

Location:Meist völlig betrunken in der Hofnarrenkammer

Interests:Lavalampen stundenlang anglotzen

Posted 05 October 2017 - 19:10

No no, Renoise is not really this important during an interstellar flight,

though if one of the navigators is a real nerd, he will have it running on his dedicated entertainment interface. So he can kill some time being creative while loosely monitoring how things are going with the warp engines. And during the party that is done while 2 teams are awake, for that every-16-months-crew-shift-change, he can greet his comrades with some pretty cool music once their senses are less foggy from being rewakened from their cryostasis...

Also the "R" logo looks nice as a radiation proof sticker on the outer space helmets or even landing modules, not sure about proper use of the thong in an interstellar space travel context. The thong thing must have something to do with that inofficial info of how to fit 2 persons into the cryostasis sarcophagus & rewire its controller hardware to delay the onset of narcosis until those 2 lucky ones have enough from each other for good...