What enhancement I need or want in Haiku?

It doesn’t do audio currently. It would be possible to pass audio buffers around the paths and have elements process those, but I’m not sure how ‘realtime’ it would be (which is important to me). Csound does its buffer processing sequentially, though, and I find that quite happily realtime.

However, it really is intended for a different kind of processing than those other schemes. I typically use it to “enrich” the MIDI events from my keyboard, adding extra instrument voices, switching them by footpedal, and so on.

I frequently use it to drive a Csound orchestra, though. Haiku’s flexible MidiPort scheme makes that easy. Yes, I do have Csound in Haiku :grinning: (Csound) It’s only Csound5 (they’re just about to release 6.10 for the rest of the world), and unfortunately the arrival of PM royally screwed up its installation, but it runs fine once installed. I’ve forgotten exactly what I had to do, but if you want to try installing it, I’ll revisit my memories.

Just for fun, here’s my “Hammond Emulator” (using Csound):

1 Like

So this is Weaver interfacing with CSound using internal MIDI interfaces right?

That’s sort of the thing that OpenMusic does, well, except using Common Lisp to script MIDI generators if needed, so yeah this is really what I was hoping to find.

If you do find how you got CSound working, or another similar program like Pure Data, SuperCollider or ChucK, I personally would really appreciate a small guide on how to get it all up and running. It would really help Haiku to progress to the multimedia OS that BeOS was.

1 Like

One of the better SoundFonts is called “Titanic 200 GM-GS SoundFont”, I think the latest version is 1.2 (I used 1.1 couple years ago). It’s 200Mb, but it’s very nice. There’s also Crisis General Midi 3.01 (CGM3.01) uncompressed sf2 package, but it’s size is close to 1 gig.

ha, i’m putting together a video switcher that uses MIDI

USB Wi-Fi would be great (802.11n).

1 Like

Exactly. I’m doing things in a slightly convoluted fashion for my own convenience. I actually run Csound via a command line in a Weaver module (top right in the image above). I could also run it from a separate Terminal, of course, but this way everything starts up with a click to load the diagram, and quits cleanly when I’m done.

I should note that one reason I use Haiku is its superb MidiProducer/MidiConsumer scheme. AFIC it beats any other OS by a mile! The configuration above defines a ‘hammond_in’ Producer port (panel hidden in the picture) and the hammond.csd file links to that in its parameters. All automatic once it’s set up. (The “Rcv from: hammond” panel that’s visible is a Consumer that let’s me send in MIDI from somewhere else via PatchBay.)

I’m looking at how to make Csound straightforward to install on a current hrev. Don’t think anyone has tried porting any of those others. The problem is that the demand seems to be small. Giovanni is the only other person I know to have used Csound on Haiku. He even ported CsoundQT at one point. Had a few annoying bugs (QT’s fault, I think), so I didn’t use it much, and I don’t know if it still works.

And getting back to “what I need or want in Haiku” :slight_smile:, I still find general audio handling to be rather deficient. In BeOS, Cortex could actually be used to switch audio streams around; never been able to do that in Haiku. And I’m not sure how many audio drivers can be used for realtime output. My machine is HDA, and the supplied driver has an unacceptably long latency. I patched it long ago to match the Aiuch driver which has a settings file to adjust buffer size and count. The patch has been sitting in the bug tracker for years; can’t seem to persuade anyone it’s important! [It’s on my website if anyone needs it.]

It would also be nice to have USB Audio working. The AUDIO IN on my laptop is useless (in Linux, too) but I have Behringer UCA202 that would do the job nicely via USB…

1 Like

It’s indeed something we should fix, but not by asking users to tweak a setting file. We should just use a more reasonable buffer size by default, and if we can’t really get this working automatically, integrate the setting in Media preferences. What’s the point of having a nice preference panel, if each driver just grows a custom settings file instead?

Yep – that would be nice…And I’m sure someday someone will have the time and motivation to code a spiffy Preferences panel for it. Meanwhile, a perfectly adequate solution – necessary to me and some others – has sat ignored for five years. I should be clear that my patch is an exact replication of what Korli did for the AUICH driver. That has an “auich.settings”, I have “hda.settings”.

I’m not even sure that a text settings file isn’t more appropriate here than a panel. It’s something one will normally set once for their machine, and never touch again. I’ve occasionally experimented, but otherwise it’s set-and-forget. Certainly one could adjust the default buffers to a better value – an even quicker patch! – though there’s the danger that it might no longer be correct for, say, older machines.

In any case, it seems wrong to deny a particular solution that is perectly good and needed by some people simply because you think there ought to be “something better”. As this is a volunteer project, I’d think it more reasonable to accept a fix that someone has taken the trouble to implement. This sort of thing is one of the reasons that my enthusiasm for submitting patches has waned considerably.

I hate to use this forum to make what may seem to be a complaint, but I’m finding myself in agreement with Pete about “perfectly adequate solutions” that sit, “waiting for something better”. In my case, it would be the printing proof-of- concept discussed in this trac ticket: https://dev.haiku-os.org/ticket/6761.
For the life of me, I don’t understand why we can’t fix things for which a solution is in hand now, and leave the grander solution for a later date. This is especially true of basic end user functions like printing.
This project just cannot afford to lose any more contributors.

In the case of that printing thing, I made the patch myself. And I’m not lost.

The problem is the long-term maintenance. Have you noticed how rare “this code is crap, let’s rewrite it all” moments are rare in Haiku? This is because we are very strict about what gets merged. We only accept the right solution, and only if the code is cleanly formatted. From the users point of view, it would seem that this is not needed. There is this less perfect solution getting the work done.

But if we start accepting such things, over time, the overall code quality degrades. People are uncertain why a certain piece of code is written the way it is. Maybe there is some subtle thing they don’t understand. And when they try to make a change, everything falls apart.

Let’s take this concrete example of printing, since you bring it up. The core of the problem is inside app_server. The patch I put in that ticked is in the interface kit, which means the problem is not fixed in app_server, it is just hidden. Now the bug is just waiting to pop in another place. Maybe another edge case when printing, or maybe in something unrelated (such as using the remote app-server). In some years, another developer will hit it again. He will have to investigate it, spend a few hours understanding what is going on, and then try to fix it. Maybe while doing so he will break printing again because the workaround relies on the bug to exist.

Basically, allowing such changes makes the software more brittle and after some time, any attempt to change something makes something else fall apart. Until someone gets frustrated and decides to rewrite it all. Then it usually ends up with the new, supposedly cleaner system having less features and more bugs (because it’s not done), and the old system being ugly code, but still somewhat working, and it is very hard to decide when to move from one to the other, because there could still be regressions. Also, we don’t have enough devs to get started on a rewrite of anything.

The cleanliness and readability of the code is the important part here. Features come only second to that. As for attracting new devs, if they are not willing to go the extra mile in making the code perfect, I’m sorry to say I prefer not to have them messing with Haiku sources.


Maybe it’s too early to ask, but what is the current status of OpenVPN preflet implementation? I guess @kallisti5 was working on it, is the development still alive or are there any plants at all to roll it out some day?

1 Like

Enhancements which I’d like to see are related to reliability of connections.
For me Haiku is pretty stable on all my devices: recently I installed it also on two old laptops (Asus Z8110G and Sony Vaio VGN-FS215E) and it gave new life to these laptops!

However, an issue that I already encouter is about the reliability of ethernet and wifi connection, also on my main Desktop (modern computer):

DHCP and WiFi, for me, are unstable and unreliable:

I use 3 level keymap (3th level with alt-option key), and I run in some problem with hotkeys with alt (option), can I change that to control?

For example I have ‘+’ on 3 level, and I cannot use command+option+’+’ in Tracker window, because when I press command and option keys system seems expects hotkey from first keymap level not some command+‘some 3th level symbol’.

Can be this option of asigning hotkey key between control and alt(option) added to Haiku?

3 levels keymaps are common for non english users.

I havent really read every post in the thread to be honest, so I apologize if this has already been mentioned.

I miss some kind of “Exposé” function, like on Mac OS X. You press one button and you instantly get a view of all your open windows independand of application, so you can select the one you want frontmost with just one click. An example in the Linux world is Gnome 3. If you press the Windows key you get the same kind of feature.

I can do without it of course (I am right now), but it’s the one thing I really miss from my Mac.

1 Like

There is a cntr+tab for that, may be in more older style, actually this feature can be extended (as option) to minimized windows instead of apps icons.

Yes, I know there’s ctrl+tab, it’s what I use now. What I’m missing is something like that, but handles all non-minimized windows instead of toggling whole applications like ctrl+tab does.

This explains it pretty well: https://support.apple.com/en-us/HT201741

An Exposé like feature might need compositing to be efficient, I dunno. Personally, I’d settle for an updated “Twitcher” (CTRL+TAB) that uses bigger icons and a wider window.

There’s also Axel’s “Switcher” (not in the image, but in the code under src/apps/switcher/), which I like very much, but forgot about… :slight_smile:
Just people not comfortable compiling can see it, I have built it and uploaded it: Switcher.zip (32bit)

I’ll let you explore yourself, and just hint: while running several apps with several windows on several workspaces, launch Switcher, hold CTRL and move the mouse to the different screenborders.

For haiku I would like to be able to put every user in a container. Does that mean every user has his “home” directory which is in a container.

Only in this, the user may install his programs (system only admin). Thus one could have several users on a computer (family), without which the program of the other one is available for everyone and also the data surely.

Would be a nice thing for the user “homebanking”, because you would install only the necessary and therefore the danger is lower that malware installed.

Twitcher has always been a favorite of mine going all the way back to BeOS :slight_smile:

you can already install programs in home/config/packages. it’s just not reachable from tqe ui so you have to copy hpkg files there manually.

Now if we supported multiple home directories for different users… That’s pretty high on the R2 todo list however.

1 Like