Poll - What recorder and/or sequencer do you primarily use?

[Smurf43]

Mixbus, and am getting ready to purchase the linuxDSP plugins...I'm tired of fighting pure linux stuff & just want to get down to making music!!

Mixbus 2.2 runing on Mint Maya with no problems & totally acceptable lantency (7ms)

[dednikko]

What did you select? Ardour and LMMS
What work do you do? Recording small bands, lots of personal projects of my own, live performance.
You mainly deal with - Both audio and MIDI

If you voted for more than one option, for what tasks do you prefer each program? I use ardour to record audio, and as of A3beta5, MIDI. The lack of stability keeps me from doing much more than experiments in Ardour for MIDI. Ardour ends up as my "mixer" of sorts with live performance. I have a limiter set to keep sounds guys from blowing a cone. I have SC3 set to allow me to interrupt the recorded tracks with sample bursts, and I send vox through Ardour as well.
LMMS is used for composition and basic mixing. Ardour is used for all polishing and sample editing.

What else have you tried earlier before settling on your current choices? What caused you to leave from your previous programs? Are you looking to shift to a different program from your current one? I have ATTEMPTED to use PyDAW, Rosegarden, QTractor, Renoise and Energy XT. Maybe it's that I was trained on FLStudio and Sonar, but I can't seem to grasp the other editors or get them to do what I want. This is frustrating as some of them and their related projects intrigue me. I want to use Euphoria live how I used to use Native Instruments' Battery standalone, but I can't get it to make a peep. Ah well, Hydrogen fills that niche, but I would like a straight up sampler without the added complexity and visual clutter of the sequencer. I know that DrMrSampler kinda makes Hydrogen usable as a plugin in a DAW like Ardour similar to how I'd use Battery, but without sample editing, sample changing/kit editing and effects in the plugin, it seems too cumbersome compared to what I'm used to.
Is there anything you find missing in your current program, or something you wish was improved? I wish LMMS has a more polished export dialogue, including the ability to export all tracks as individual .wav files. I wish I could get Ardour 3 Beta5 to NOT crash when I remove any LV2 plugin and try to save.

[danboid]

Hi dednikko!

You do know that samplv1 works as a standalone JACK app if you want a bare bones sampler right?

I have no interest in using LMMS as I think qtractor and Muse are far superior FOSS sequencers but I am on their mailing list and I'm sure I recall recently reading that someone has added the wav track export feature you want to their svn/git repo so maybe you should check out their latest code?

[jeffh]

I have ATTEMPTED to use PyDAW...

*I wrote PyDAW*

I'm willing to help if you have questions... Although to be honest, the only audio capabilities it has at the moment is to load .wav's in the Euphoria and play them back using MIDI, so if you're recording bands it's probably not the best tool for you(yet). But it is only 3-4 months into development as of today, so I know that I still have plenty of work to do. Also, depending on when you tried it, it may have come a long way since then... If the version you tried looks nothing like the screenshots here, it may be worth trying it again:

http://sourceforge.net/projects/libmods ... rce=navbar

Also, I'm planning on pushing out a big update today, which mostly addresses almost all of the (mostly minor) bugs I've found since I began "eating my own dogfood"(tm) earlier this week.

I want to use Euphoria live how I used to use Native Instruments' Battery standalone, but I can't get it to make a peep.

*I also wrote Euphoria*

It should just be a matter of using the navigation panes on the left side here:

http://sourceforge.net/projects/libmods ... phoria.png

Browsing to the folder that your samples are in (you can click the 'bookmark' button to save that folder as a bookmark), then select one or more samples in the bottom-left pane and click the 'load' button, where they will be loaded sequentially started on the row with the selected radiobutton. Then you should be able to play it with your MIDI keyboard(connected from the ALSA tab of QJackCtl) or in PyDAW(or possibly other DSSI hosts, although Muse2 for example has known issues with it's DSSI support). If you intend to use it for drums, there is a "map all samples to 1 white key" option in the tool-strip menu(top of the window(or top of the screen in Ubuntu)) that maps the samples out from C1 upwards one white key at a time. If you need additional help, let me know what you're trying to do and how it's not working...

EDIT: Also, you can assign individual effects to individual samples within Euphoria on the "MonoFX" tab by selecting a sample, then selecting a different sample group for it. You can, of course, also group samples together into the same effects group... My entire rationale for Euphoria was to provide a libre replacement for Kontakt and Battery without the bloated, over-done interfaces, so I aim to please for people who miss their Native Instruments plugins

[dednikko]

Excellent. I will try to get the updated euphoria tested and rocking on my performance system soon. I currently have This interface:



Clicking arounf the interface I definitely got excited and envisioned it working similar to Battery. I have a Korg Nanopad that needs a good software mate.

If/when I get the setup configured, I'll post a reply with my successes and experiences. Just so I'm clear, do I need a DSSI host to run Euphoria? I have it available to run as a standalone in Dream Studio.

[dednikko]

u4ia1.png

hmm. let me try to upload the images here instead.

[dednikko]

Perhaps there was something fishy with my system and the previous version, but I have Euphoria up and running after that last update! I have built a pretty heavy kit and so far it is rock solid. I'm going to pipe it into Ardour 2 and have it into the mains and the sidechain compressor that controls it. I'll play with it for a few days and let you know if I run into anything major.

If I could add a single feature, it would be a simple, one knob bit-crush effect. Speaking of knobs, is there any midi-learn capability or mapping options?

I do of course understand that this is rather fresh code, so I'm not saying that you ought to have these things already. This is spectacular for the amount of time you've been at it. Keep it up, and I'll try to get my fellow elecroic musicians to give it a spin and support.

I'm liking to UI updates too.

[jeffh]

Perhaps there was something fishy with my system and the previous version, but I have Euphoria up and running after that last update! I have built a pretty heavy kit and so far it is rock solid. I'm going to pipe it into Ardour 2 and have it into the mains and the sidechain compressor that controls it. I'll play with it for a few days and let you know if I run into anything major.

Glad to hear it. I think Euphoria is well positioned to fill the same niche that Kontakt and Battery do for Windows, it's obviously not a one-to-one clone of either, but if you're looking for that same kind of modularity they offer, it's pretty much the only game in Linux-town right now... Of course, I have big plans for a Euphoria v2.0 that will greatly improve what's already there...

If I could add a single feature, it would be a simple, one knob bit-crush effect.

I've been meaning to create such an effect for over 6months now, it just seems like I always have bigger fish to fry

It's on my TODO list for the next version, here's a list of the goodies I have planned:
Bit Crush
Sample Rate Reduce (an actual high quality one that buffers>downsamples>upsamples>filters, not those screetchy ones that sample-and-hold)
Morphing Filter Types (like LP>HP, BP>LP, LP>BP>HP, etc... maybe even some of the more exotic ones like in the old E-MU Z-Plane filters)
Reverb (probably just using Freeverb)
Convolution Reverb (probably just using Freeverb again...)
Dry/Wet knobs on as many effects as possible, so that they can be bypassed on the fly...
Knobs akin to the 'Modulation Macro' knobs on the NI plugins, where you can assign one knob to move multiple controls in various amounts/directions...

Speaking of knobs, is there any midi-learn capability or mapping options?

There are CC map files for them in /home/your_user_name/pydaw/*cc_map.txt. For safer editing, probably best to edit them in PyDAW on the CC Maps tab(I actually haven't exposed every knob on the interface to CC modulation yet, but I think I got all of the ones you'd really need to move)... Because PyDAW and all of it's plugins are currently based on DSSI, MIDI-learn is somewhere between difficult and impossible to implement. However, I'm breaking away from DSSI compatibility in the next version, so I should be able to implement MIDI-learn once I start re-working my plugin format.

I do of course understand that this is rather fresh code, so I'm not saying that you ought to have these things already. This is spectacular for the amount of time you've been at it. Keep it up, and I'll try to get my fellow elecroic musicians to give it a spin and support.

I appreciate it

I'm liking to UI updates too.

Don't thank me, thank the countless other open source projects that I nicked all of the Qt-CSS from to piece together that color theme

[danboid]

Jeff - your plans for Euphoria sound fantastic so it'd be a great shame for qtractor, MusE and rosegarden users if you drop DSSI support as we have precious few decent Linux native samplers.

Thanks to qtractors qtz session archive support, I suspect Euphoria using sessions should be portable but I'm not sure it'd be as simple to share MusE sessions that use Euphoria - anyone tried this yet? I'll have a go over Chrimbo if this is unknown territory.

As you've likely noticed by now, I've started a new DAW poll with what are in my opinion a much better selection of options than was originally presented so please could you all re-vote so we get know who voted Ardour when they really meant Mixbus, just how popular qtractor and Supercollider really are and much more!

[jeffh]

it'd be a great shame for qtractor, MusE and rosegarden users if you drop DSSI support

But does Euphoria work properly in any of those DAWs? Not last time I checked, Qtractor had a few bugs(including some heap corruption that screws up state-saving) and potential crashes, Muse has stuck notes and/or missed notes and crashes, and Rosegarden crashes quite a lot. You seem to be seeing things my way regarding Muse2, as evidenced by your recent post, and the recent barrage of bug reports you filed in their tracker...

But the reference DSSI host by the DSSI developers always worked, and I created PyDAW based on the reference host and it too hosts Euphoria flawlessly. Therefore, there's no reason to knee-cap my plugins' potential just to preserve compatibility with hosts that have had buggy DSSI support since forever... So the idea is that PyDAW and it's plugins will continue growing rapidly until they become the premier Linux DAW... and there is a huge performance/feature advantage to be had by stripping out DSSI support and making the plugins truly integrated with PyDAW, such as my plans of making individual samples in Euphoria directly routable to busses in the PyDAW mixer. I can do that even more elegantly than Kontakt in Cubase/Reaper/Ableton can because I control the plugins and the DAW.

If it's any consolation, the current PyDAWv1 and it's plugins will be able to be installed in parallel with PyDAWv2, PyDAWv3, etc... but I'm not going to limit my plugins potential in PyDAW as a favor to any of the other DAW developers, sorry... and since it seems that the possibility of you ever adopting PyDAW as your main DAW has not ever crossed your mind, then maybe it's best that you don't get too attached to Euphoria either... DSSI is a dead standard, and I'm replacing it with my own plugin standard that will fix all of it's shortcomings, it's not a matter of "if", but of "when"...

[jeffh]

The lv2 main author is the one that codes ardour lv2 support, so it has the best possible support.

First of all, I'm no fan of Ardour. They're finally going to release Ardour3 with "MIDI support" even though it's still not stable after so many years of delay...

But more interestingly, Dave didn't just do Ardour, he apparently helped Rui with LV2 in Qtractor and his plugins, implemented LV2 in the CALF pack, and probably also implemented LV2 (or helped) anywhere else it is being used Did Steinberg have to help anybody implement VST? Heck, Windows developers all complain about the VST format, and yet everybody can still make it work...

We're all just worried that you end up doing something new and totally different, which no host will be able to load (if you're serious about doing your own plugin spec, of course).

PyDAW v1 will not lose DSSI compatibility, so you'll have the current plugins mostly as they are today(with only bug-fix updates, and possibly a port to Qt5 if it's not too much work). However, as I said, I intend to make a truly integrated DAW/plugin experience, so the other DAW developers wanting/needing my plugins is not my concern. They were all offered a chance to collaborate with me and all turned it down, now that I've written my own DAW, they won't get that chance again.

I personally won't use PyDAW, but would use the plugins if they work on a specific plugin spec.

Why should I care about the other DAWs for people with that kind of attitude? PyDAW is still very young, but the hardcore-Linux-audio-afficionados all seem to be dead-set against ever using it, because they have loyalty to other developers, and don't want to ruin those friendships.

What exactly is broken about the current DSSI hosts implementation?

Have you tried them?

I have my own host (getting it ready for release), and I'm working towards perfect spec support with it.
I do want to make your plugins working perfectly with it, really. I'm open to all kind of suggestions on how to improve it (just need a little time to clean it up).

Test them thoroughly, Valgrind your host until it gives no more memory errors, and don't expect the plugins to magically re-order the MIDI events to their logical order (ie: everything the current hosts didn't do).

I've hinted at my feelings about LV2 before, but I'll share them again

1. I'm sure he's a really nice guy, but Drobzilla has been in college for over 20 years. He's never held a real job, and he's never finished any piece of software that he has started(as evidenced by the many half-baked-wonders in his personal Git repo). I'm not sure who appointed him to be the standard-barer for plugin format design, and I don't know why everyone sat around and waited 7 years for him to finish LV2, then he's already bumped minor versions twice in less than a year since then, but I'm going to start my own plugin standard to compete with LV2 that will be simpler to use and have a more sensible feature set, and I'll finish it in a fraction of the time and bump versions as little as possible. There's nothing wrong with a little competition, right? and if I do a better job than he did, then everybody wins. However, harsh as this may sound, based on all of this work that I've seen, I have no faith in the man behind the standard, so therefore as long as he owns it, I have no faith in the standard. Of course, you or anybody else are welcome to fork Euphoria into an LV2, or better yet, implement my new standard in their hosts.

2. I intend to do things DSSI can't do, but I also intend to do things that LV2 can't do either. Most Linux audio developers are general purpose developers rather than DSP developers, and most tend to 'recycle' other libre DSP code for their own(not that there's anything wrong with that, but limited understanding of DSP doesn't help them either)... I started out as a DSP developer many years ago, and the core of PyDAW and it's plugins is a high performance/quality DSP library that I wrote myself from scratch. If anybody is qualified to 'get it right' with a plugin/host format, it's me. I think Euphoria is perhaps already one of the best examples of "advanced exotic DSP technique" in all of open source, how many other plugins implement multi-pronged indexing schemes, advanced audio/modulation routing schemes and silly amounts of modularity?

Like this from Euphoria's MIDI processing loop, it's f'ing hardcore to use a 4-dimensional array for an index like this, right? The below code is the main reason Euphoria uses <5% CPU at idle instead of 30-40%...

Code: Select all

//Calculate an index of which mod_matrix controls to process.  This saves expensive iterations and if/then logic in the main loop
for(plugin_data->i_fx_grps = 0; (plugin_data->i_fx_grps) < EUPHORIA_EFFECTS_GROUPS_COUNT; plugin_data->i_fx_grps = (plugin_data->i_fx_grps) + 1)
{
    for(plugin_data->i_dst = 0; (plugin_data->i_dst) < (plugin_data->active_polyfx_count[f_voice_num]); plugin_data->i_dst = (plugin_data->i_dst) + 1)
    {
        plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])] = 0;

        for(plugin_data->i_src = 0; (plugin_data->i_src) < EUPHORIA_MODULATOR_COUNT; plugin_data->i_src = (plugin_data->i_src) + 1)
        {
            for(plugin_data->i_ctrl = 0; (plugin_data->i_ctrl) < EUPHORIA_CONTROLS_PER_MOD_EFFECT; plugin_data->i_ctrl = (plugin_data->i_ctrl) + 1)
            {
                if((*(plugin_data->polyfx_mod_matrix[(plugin_data->i_fx_grps)][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])][(plugin_data->i_src)][(plugin_data->i_ctrl)])) != 0)
                {                                        
                    plugin_data->polyfx_mod_ctrl_indexes[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])][(plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])])] = (plugin_data->i_ctrl);
                    plugin_data->polyfx_mod_src_index[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])][(plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])])] = (plugin_data->i_src);
                    plugin_data->polyfx_mod_matrix_values[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])][(plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])])] = 
                            (*(plugin_data->polyfx_mod_matrix[(plugin_data->i_fx_grps)][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])][(plugin_data->i_src)][(plugin_data->i_ctrl)])) * .01;

                    plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])] = (plugin_data->polyfx_mod_counts[f_voice_num][(plugin_data->active_polyfx[f_voice_num][(plugin_data->i_dst)])]) + 1;
                }
            }
        }
    }
}

[alex stone]

Jeffh,

What do you have in mind for a universal linux plugin format instead of lv2?

Alex.

EDIT: Ok, i've read again and you seem to be ok with DSSI. Any plans to contribute, improve it, add new features, etc?

[jeffh]

EDIT: Ok, i've read again and you seem to be ok with DSSI. Any plans to contribute, improve it, add new features, etc?

I'm glad you asked... Rather than some overbearing behemoth of a plugin format with 20 different components like LV2, I'm going to fork my standard from DSSI, but with the following improvements:

1. Liblo/OSC is out for GUI->plugin communication, in favor of either DBus, pipes, or sockets...(which ever I find most reliable and robust)
2. The back-end will have better ways to send messages to the UI
3. Both host and plugin will get an actual API/library to make implementation easier, rather than an SDK and a few reference designs to copy like DSSI..
4. Better audio routing options
5. A more sensible way of creating control ports that doesn't cause re-ordering to break backwards compatibility
6. Event-driven control processing, instead of costly table scans(Euphoria has over 1100 controls to scan, believe it or not)...
7. More options for the type of value to send, rather than just casting everything to a typedef'd float and having to cast it back to int or whatever.
8. Plugin delay compensation reporting

..and otherwise, it will be kept as simple as possible. DSSI mostly got it right(once the Liblo networking bugs got worked out, not their fault though), it just needed a bit more work to modernize it.

[jeffh]

I never turned down a chance to collaborate with you (...did I?).

No, but you did pretty much say that I was an arrogant prick who boasts too much, which isn't going to make for very good relations between us

You'll be "hurting" other developers and users that are not guilty of this.

I'm not concerned about other developers. I'm developing my own stack of applications, so I don't have a need for their applications.

I've seen you rant a lot about current DAWs, but your plugins have probably have some flaws as well.

*probably* aka: you're not sure because you haven't really used them There are only a couple of flaws that I know of, and I haven't fixed them because frankly, they're not that important. But I have Valgrind'ed (Valground?) the entire suite to death, and wrote a test bed to play back an entire PyDAW project disconnected from ALSA/Jack through GDB or Valgrind(including simulating external MIDI events), and can say with absolute certainty that everything is free of buffer overflows, conditional-move-or-jump-depends-on-unitialized-values and so on... Maybe you should give PyDAW a try, it's unbelievably stable for a DAW that's less than 4 months into development... There may still be bugs lurking around with such new code, but with my commitment to both automated and manual QA/testing, I will hunt them down and squash them sooner rather than later.

The last release you made of libmodsynth didn't load in Renoise at all (and that is a pro-grade DAW, err tracker, not a toy).

LOL, Renoise is still a very small player compared to Cubase/Reaper/Ableton/ProTools(/Sequoia/AcidPro/MicrosoftSongSmith)... Show me a real "pro" who uses Renoise, then we can give it "pro" status... My plugins work in jack-dssi-host , the reference DSSI host design, therefore they should work anywhere DSSI plugins are hosted... But they didn't, so I wrote my own host based on jack-dssi-host, and everything "just works".

What attitude?

That you switching to PyDAW is never going to be an option.

Some people have just criticized you a little bit, but mostly because of tend to get overzealous about your software.
I don't get this...

Richard Stallman also catches a lot of flack for the same thing

drobilla did finish a lot of his projects (Raul, Flowcanvas, Patchage, the whole lv2 stuff).

Patchage wasn't very stable when I tried it, I don't call that "finished".

why are you so quick to rant people?

I don't know, I've been like this since I was 5 y/o...

I understand that you know your way around computers, coding and DSP, but your PR skills need some work...

I'm not concerned about PR or playing politician, I think the best PR is a killer product that's too good not to use... PyDAW isn't there yet, but I think it would compare favorably to any DAW or plugin suite, free or commercial, that's so early into development(by a single person, in his spare time, much less). In a couple of weeks, it will be the one-year-anniversary of me beginning work on my project. At this time next year, I expect to have taken it completely to the next level, now that I have a solid foundation and a focused project. Let's look at other software developers who are dicks:

Native Instruments: dicks
Steinberg: dicks
M-Audio/Avid/Protools: dicks

...and yet everybody still gives them money and uses their software

I still haven't gave up on LV2, because it will hurt users.

Linux is a democracy of competing projects and standards. How many times has a component of the Linux kernel been replaced by a superior competing project? It's evolution and natural selection, the cream almost always rises to the top, so this will be a competition between me and Drobilla. May the best man win...

anyway, I hope you the best, and happy holidays btw.
Don't let my words hurt you, that's not my purpose.

I just want a happy community here.

Same to you, buddy

[jeffh]

But you'll get much much less users that way, although I suspect that's what you want...

I'm not concerned about total user count, but I am aiming to attract new users from Windows/OSX to Linux, rather than fighting over the same 20 people who post on LM... I'm aiming to grow the pie with something unique and compelling, rather than stealing somebody else's slice of the pie...