I'm curious, how many of you still really use the EigenD features, compared to plain MIDI, OSC and AudioUnit/VST...
I'm curious, how many of you still really use the EigenD features, compared to plain MIDI, OSC and AudioUnit/VST hosting. Who uses the recorder, the drum loops, the built-in clarinet and cello, the modular synth, talkers, stage, belcanto, ...?
I've used it as a flexible midi controller since the first day, basically getting its software environment out of the way as much as possible.
ReplyDeleteLikewise - I use the arranger very occasionally, sending MIDI to a drum track in Ableton, but I could live without that if it wasn't there. I've never found the drum loops to be flexible enough and they seemed to eat CPU and add a long time to the setup load, so I have a setup based roughly around Factory 2 but with everything except the MIDI ripped out to save load time and CPU. I don't use any built in VST/AU hosting as they caused too many crashes and it seems as responsive to host elsewhere and send MIDI to control them. I did like sound of the built in synth, but it was a pain to configure compared to something like Reaktor, so I never use it these days.
ReplyDeleteThe reason I'm asking is because I'm wondering if it would be worth making a different type of software for the Eigenharp that just focuses on setting up keygroups with scales and generating MIDI, maybe do AU/VST hosting. It would make the source code a huge amount simpler to maintain and make it possible for someone else besides Mark and me to contribute. Sadly, with the current EigenD and the Eigenharp relying on it so much, I'm afraid it on its way to a slow demise due to the sheer complexity.
ReplyDeleteHave one patch for the Pico with fingerer that uses the clarinet or midi out (switchable via talker).
ReplyDeleteBesides that I mainly use one patch with some keygroups, scalers and rangers and lights for diagonal layout and a midi out. Hosting is done in Usine. Then the same with two split areas (to play two instruments)
These are the only three layouts I have used for a long time.
Played around with the integrated synth components but tend to use other ones (e.g. Diva) more often.
Have never really used the recorder, loops, arranger etc. stuff.
That would be superb from my perspective Geert. The 'must have' features for me would be keeping the MIDI routing matrix (which is superb) & Mark's scale illuminator which I use all the time.
ReplyDeleteThat would be fantastic! Was thinking the same thing myself the other day.
ReplyDeleteSadly supporting the Pico in other open source software might be a problem since the firmware is sent to the Pico upon EigenD startup and the code of the library that does that is not open source. So if I was to work on this barebones application, it would only be for Alpha and Tau at first.
ReplyDeleteThat would be awesome, indeed! EigenD is very powerful on the outside but also intimidating on the inside. A layout editor with zones, blinky lights and a midi matrix would already cover a lot of ground. Probably wouldn't replace EigenD for all scenarios (e.g. Pico users or those who use the more fancy features of EigenD) - but nobody stops us to continue to use EigenD for these cases as long as it runs.
ReplyDeleteI use my Alpha as a very sophisticated MIDI controller and VST host. I definitely use Stage, which means I have to use EigenD Browser (to select scales and VST plugins, mainly). Like several others, I use only two setups: one based on a single keyboard with a block of keys at the top to use as controllers--some have low MIDI notes assigned, to be used as keyswitches, two are octave keys, and four are continuous controllers, with movement in each of the three directions (potentially) assigned to different CC numbers. The second setup divides the keyboard in half, to allow me to play two instruments--same controller block at the top, identical controller block at the bottom.
ReplyDeleteBasically, I have stripped out everything else. But unlike Mark Harris clever strategy of quickly creating very simple setups, I used WorkBench and the MIDI Matrix to replace the removed selections with 12 immediately selectable MIDI "patches", so I can immediately select a patch optimized for a piano, or a pipe organ, or a synth, or an electric piano, or a plucked string, or a bowed string/blown horn. Likewise, 4 VST patches, with different controller characteristics....
Never use recorder, drum loops, built in sounds, built in instruments, built in synth, belcanto, microphone, headset.
Definitely use ability to pre-load and quickly select 6 to8 scales/modes, and to transpose the key. I use Stage regularly to make changes on the fly--but simpler would be fine. WorkBench was critical, but enormously frustrating to use in creating my two setups (over 3 years, and over 450 saved iterations). This whole thing could be much much simpler, and still provide the tools to customize the most flexible and nuanced controller on the planet!
Definitely need to be able to light certain keys as markers... 120 identical keys is just not workable....
So I am absolutely convinced a much simpler EigenD is the way to go. BUT if these are to be anything other than oddly-shaped piano keyboards with three degrees of key movement--if we want to be able to optimize for different types of voicing, albeit using MIDI or VST automation, we need to keep a few of the tools--including a few rudimentary talkers, I'm afraid....
I'm no programmer. Would love to see some of you that are take a run at a leaner machine. Would be glad to help, with documentation aimed at non-programmers, perhaps with some modest funding.
Good idea, Geert Bevin
A case of less is more?
ReplyDeleteDrop all the “bells and whitles” and focus on the sheer necessity?
LinnStrument resonates here so much (now that I have one; I still embrace challenges and look away from
keyboards “piano-forte”)
Also in the AU/VST hosting department GigPerformer is a good example of a new prespective.
So, YES why not something like EigenD lite, just dealing with the keys, strips, breath controller.
As you mention Geert Bevin just plain MIDI and OSC.
My uses:
Instrument management purely; scale illuminator, Live pad, all Midi agents ;-)
AU Hosting only Pianoteq to take advantage of Hi-res velocity CC88 everything else to something multi-thread.
EigenD T3D/OSC
Justin Dune do you use Stage on the computer or on iOS? This very basic version of EigenD would have a GUI to select what you need, so you can just click it, no need for Belcanto, etc.
ReplyDeleteFerdinand Strixner exactly, that's where I'm getting at, and it would provide something we can maintain as a group due to the simpler code base
ReplyDeleteAntónio Machado thanks! What do you mean with Live Pad?
ReplyDeleteIve been gradually weening myself off EigenD agents, as I see this as almost inevitable eventually (and have been moving this way with MEC)
ReplyDeleteId be very willing to contribute/collaborate on such a project.
Ive gone down to:
- MIDI 'plain', notes on/off, CC1,2,9
- MIDI MPE
- OSC
- configurable keymaps
- simple menu for switch between targets/keymaps
- simple leds for menus, and static 'key markings'
my intention is, everything else can be done outside ... in a DAW/Bidule/whatever...
Ive been (slowly!) working on a project as a replacement to just have this very simple functionality - called MEC
currently it:
- works with Eigenharps (and soundplane, push2)
- has a simple key layout definition.
- sends out MIDI MPE / OSC
it runs on Mac/Linux (including Beaglebone Black (BBB) /PI) ... its cross platform, but just not added windows support. Its pure C++ using CMake, so very simple to work on :)
my aim with MEC is simple, to run it on a BBB, so that the Eigenharp ( & Soundplane) can be considered a standalone instrument, to avoid these OS upgrades issues.
Id plan to publish the code once I had v1.0 ready, but Id be happy to publish it now if you wish.
I dont think it should be the basis for this project BUT it may have some code fragments that may be useful.
p.s. there is a GPL 'loophole' that means the pico could potentially be supported ;) - but such tech discussion should probably be elsewhere.
ReplyDeleteMark Harris there does seem to be quite some overlap, I was planning to have more than just Eigenharp support also and to add plugin hosting with some features that I need for live performance (like coordinated preset switching, click track, coordinated tempo switching, mixing, ...). It feels that it would be a shame to independently work on projects that are so closely related. My plan is to base things as much as possible on JUCE for all the obvious benefits and to have a very thin layer that does the Eigenharp to MIDI/OSC conversion, then handle all the rest as audio and midi internally.
ReplyDeleteagreed, much better to collaborate :)
ReplyDeleteI avoided JUCE, as I wanted to be very light (due to microcomputer support), so used rtmidi...
but Im not averse to JUCE. my only 'must have' is that it doesn't need to run a GUI.
(so I don't need to mess with X/virtual frame buffers) but of course, though there are many ways to do that. (core/abstract ui etc)
I'll open up MEC later today... so you can dig around, as I say though, Ive no issue with not using any of it... so just consider it as 'ideas' etc.
perhaps we should have a hangout to discuss how developers could collaborate to help make this happen?
BTW: (sorry this is probably off-topic)
what would people say to an EigenD, that has EigenBrowser/Commander removed?
... these are built on wxPython, which basically is now completely broken. Ive looked at re-writing EigenBrowser ,but frankly its a nightmare.
(and honestly I dont use it, so my motivation is pretty low to spend months doing a re-write)
Mark Harris the GPL loophole sounds really interesting, it would be nice to support all Eigenharps
ReplyDeleteMark Harris yes, I agree that the GUI should be optional
ReplyDeleteMy position from the very beginning. I wouldn't even include hosting. Plenty of great audio hosts out there already.
ReplyDeleteI'm not even sure about keygroups, they're unlikely to suit everybody.
Give it MIDI and OSC capability and a way to determine what each key does when you push it or prod it etc, and let it just be the amazing controller that can talk to other systems to produce sound and receive commands to turn the LEDs on/off fast. I would PAY for that software!
-----------------------------------
The reason I'm asking is because I'm wondering if it would be worth making a different type of software for the Eigenharp that just focuses on setting up keygroups with scales and generating MIDI, maybe do AU/VST hosting.
gigperformer.com - Gig Performer | AU and VST Plugin Host for Live Music Performance
Geert Bevin Live Pad (previously OSC pad agent) means to control Ableton Live ;-) - MIDI remote script to LiveControl.
ReplyDeleteNice to see you guys "boiling" ideas pushing Eigenharps and MPE forward ;-)
My small helps are always at your will.
David Jameson I know of Gig Performer, but honestly besides Eigenharp support I want to build an open source hosting solution for live performance that I can use for LinnStrument, guitar, Eigenharp, Stick ... the key element here being open source. I'm tired of being dependent on third party commercial entities that can't really properly maintain nor support what I need. Yes this is very much the Not Invented Here syndrome, but for something as significant as the core of my playing setup, I've had enough of being forced to adapt and to make concessions. This is now to a point that I tweaked EigenD for my own hosting setup, but there is too much complexity and baggage. I think with how far JUCE has come, I'll be able to to quite efficiently maintain this with an open source community.
ReplyDeleteWhat is being suggested sounds like just what I would be interested in (assuming Pico can be supported)! TBH, the hassle of setting up EigenD on a fresh MacOS install has made me seriously consider jumping to a Linnstrument also... (not a dig at anyone, I appreciate the amount of effort that has gone into maintaining the current EigenD, and have looked at some of the code, so I also understand how complex it must have been to do that maintenance!)
ReplyDeleteBuilding your own audio host is a reasonable reaction to not liking what's already out there - obviously that is why we build Gig Performer. But I wasn't suggesting that the solution is for everyone to use Gig Performer (not that I would complain!). To me, the issue with the Eigenharp and EigenD has always been the notion that the Eigenharp is the center of the universe and everything should bow to it.
ReplyDeleteMy position is that the Eigenharp, Continuum, LinnStrument, whatever, are simply controllers to be integrated into an EXISTING environment that people already use and tools like Max or (if you must) PD can do a fine job of this. All they need is the basic information such as what key was pressed, how hard, in what direction, etc. If you're using Ableton, Mainstage, Cantabile or Gig Performer, it ought to be easy to integrate any of these instruments to leverage those hosts.
So yeah, I'd love to see the whole EigenD stuff dumped in favor of a simple lightweight interface that feeds MIDI or OSC to some target, whether it's an Audio Host or an intermediary like Max.
Regarding your unhappiness with current audio hosts, that's an orthogonal issue but I'd certainly be interested to know what you don't like about them. Some of them are pretty sophisticated.
I regularly use the clarinet, but many of the other features I only use when showing what it can do. I host AU/VST but only because I haven't dug deep enough to setup enough midi devices to host in a multi core environment.
ReplyDeleteI think that my current ideal setup would be to use a Pi to interpret the Eigenharp data and the spit it out to hardware or some other sound making device. I was hoping to explore this after finishing uni this year but haven't got to it yet.
Tim Roberts I wouldn't take the effort of porting over the clarinet though, so you'd have to find another way of doing this, do you think that would be possible for you with just MIDI or OSC?
ReplyDeleteDavid Jameson it's almost always the sophistication that gets in my way, every host I've tried seems to be too smart for its own good, or way too low level to build a full live setup on (Bidule)
ReplyDeleteOk, so Ive released the MEC source code, which may or may not help get this kicked off.. (see separate post)
ReplyDeleteI think AU/VST should be optional, since I some users want a 'one stop' solution, but others have DAWs/Hosts or just hardware setups... and some platforms (linux/ rPI) are never going to run VSTs due to CPU constraints.
avoiding hosting also means if you don't support microphone/headphones, you also don't have to have any audio processing, which again simplifies things a lot. (particularly as I wasn't using JUCE for MEC)
with MEC, I originally intended to be really dumb, and not have key layouts, and leave this to the 'instrument' but had to back off this, due to there being too many keys on the Alpha ... so then I realised some mapping is required, once you go there, it tends to necessitate on instrument 'menus' etc.
one thing I strongly believe, is we should start really simple, the minimum to be useful ... its easy to add things later, but I think getting something useable/stable out in a reasonable time frame drives enthusiasm.
I've had the same experience with Bidule. But I have NOT had a bad experience with Max except that its audio hosting object has become less reliable in recent versions of Max, and that was one of the reasons we decided to roll our own host. But Gig Performer deliberately supports OSC and so I continue to use Max to do all the complex processing I need, including receiving data from the Eigenharp and then I send OSC to Gig Performer to produce audio output. So the result is a decent easy to use Audio Hosting system along with the ability to interface with devices like the Eigenharp using (if necessary) glue code like Max.
ReplyDeleteMark is beating me up to add MPE support - we'll get there!
Geert Bevin I'm sure that will be fine.
ReplyDeleteMark Harris thanks Mark! Excited to get this going and great hangout chat!
ReplyDeleteThank you Geert Bevin , great chat, and Im also very excited :)
ReplyDeleteVery interested in this!
ReplyDeleteI create my setups as belcanto scripts and run them from Commander. I use Workbench for minor adjustments, but never EigenBrowser. I use talkers for octaves, scales and for running simple scripts. I don't use Stage. Audio in EigenD isn't working on my Macbook Air, but I have no need for it. I'm happy with Midi/Osc to MainStage. I like the recorders, and to a lesser degree the arranger, but since midi timing is all over the place in EigenD for me, I can't use them anyway. So wouldn't miss them much.
I like EigenD, but would be very happy to see a simpler alternative. Because of RSI issues, I try to avoid coding other than at work. But once a bare-bones version is up and running I'd probably be able to do at least some modest contributions.
Obvious from this discussion:
ReplyDeletea) existing EigenD is too complex, too fragile, and not adequately robust.
b) Much of existing EigenD's complexity would not be missed.
c) Many of our more vocal members use Macs. But--some of us are not, and in fact, current data shows about 85% of music software use is actually Windows based. So don't build it Mac-only!
d) Some people people want something really bare-bones, so they could run their machines "headless" or on tiny, dedicated micro-computers. But
e) Some in community are looking for something that provides quick control over enough variability that it could be used in performance: ability to switch between keys/scales, from MIDI appropriate for plucked string sounds to MIDI appropriate for organ type sounds. These people are going to need some kind of clear, easy-to-use GUI. Which implies computer screen--or at least tablet. That does not imply keeping Browser / Stage / Workbench, but does imply a GUI.
f) Most of us expect to integrate our instruments into larger setups: we invest in good sound source software, and DAW or at least VST / AU hosts.
g) Finally, some of our most dedicated, invested members are comfortable coding / programming. Which is obviously going to be important in building this thing--but should NOT be necessary for using it!
Keep talking!
And as Einstein said: "Make things as simple as possible, but not simpler."
Im totally behind this project, and I hope I can contribute to it.
ReplyDeleteBUT lets not confuse this with abandoning EigenD.
IMO, its way too early to consider this.
EigenD is actually still very stable, and a few of the challenges it faces, will also be faced by this project (Windows drivers)
For EigenD the main issue faced are EigenBrowser/Commander which basically are 'dead' now, and perhaps why some consider it 'unstable'.
Id still like to get EigenD into a stable state, at the moment Im trying to figure out what that actually is... including a possibility of an EigenDLite... but this is a discussion for another topic :)
Justin Dune I fully agree that this project should be cross-platform, however the burden of maintaining the code and testing it on another platform than macOS is not something that I personally have the resources for. I am working on it with cross-platform support in mind, but without people actually putting in the work for Windows (and Linux), it will never really work as well as it will work on macOS.
ReplyDeleteI'm starting to get a very clear picture of what I want this project to be, and this includes AU/VST hosting as well as other aspects that are necessary for a confusion-free and robust use of software in a live performance. Aside from the fact that I personally want something that applies to everything I use (LinnStrument, guitar, Chapman Stick, vocals, Eigenharp, Leap Motion Controller, ...), I think this application should have an identity that can potentially speak to all controllerists and musicians using computers for live performance. This will make it far easier to find others to contribute and to create a vibrant community that does not just rely on the Eigenharp users.
Geert Bevin that sounds interesting! Would be very interested in a description how this software is going to work, which grounds it is going to cover and how the instrument specific configuration UI(s?) would "plug in".
ReplyDeleteI would be interested to have Windows, Linux and (as far as it differs from ALSA-Linux) Bela support and would be willing to contribute to make this happen.
Ferdinand Strixner I've started writing this up and have an experimental architecture in place that works on macOS, validating it on Windows now. More information here: https://github.com/gbevin/HEELP
ReplyDeleteNote that this is extremely early days, only just started three days ago.
Thanks, perfect! Will have a look
ReplyDeleteGot the current experimental architecture and PoC working on Windows, so that's good news. Next I'll start working on a basic GUI.
ReplyDeleteHave started to look at the sources (thanks for getting it to compile and beep on Windows, very convenient with Visual Studio! :) )
ReplyDeleteRead the passage in juce_audio_devices.cpp about ASIO support. Really a pity that Steinberg doesn't come up with a more liberal license. On Windows ASIO support is a must, with DirectSound I get 3.6 MS, with Windows Audio 10 ms and with Asio 0.7 ms (64 samples buffer@88.2 KHz) (tested with a Surface 4 Pro and ASIO4All drivers). Perhaps we could add a put_asio_sdk here folder in the sources and add new profiles (win32_asio, x64_asio) that already set JUCE_ASIO=1.
The interfaces that e.g. the Eigenharp input, MPE input or the respective configuration interfaces would have to implement are not there yet, right?
Ferdinand Strixner I haven't added the input interfaces yet, really want to focus on getting a performance-oriented audio architecture in place first. It seems that my initial success were just luck, I'm still working through the intricacies of sharing audio buffers over shared memory in a way that works reliably.
ReplyDeleteSource like a good idea to try to handle ASIO with a manual drop-in replacement, we'll have to do the same thing for VST support anyway. Feel free to take a look, let me know your GitHub name and I'll invite you as a collaborator to the repo.
Sure, can have a look. I am "NothanUmber" on Github.
ReplyDeleteFerdinand Strixner invite's on its way
ReplyDeleteGeert Bevin perhaps if we could get a skeleton 'module' architecture in place, then others could start fleshing out other areas?
ReplyDeletebut perhaps this is too early?
... at the moment Im just 'tracking' the project, waiting for its 'shape' to become evident :)
Mark Harris yes, that's my plan, but a lot is dependent on this shared memory and separate process approach being reliable or not. If not, it's going to have a big impact on the overall design. That being said, nothing should prevent you from putting in the Eigenharp USB stuff and having it being activated in the main application, just dropping the data for now without sending it anywhere. That should already get us on the first steps of non-MIDI controller support
ReplyDeletesure... I could see you were still experimenting at this stage, which is a good idea.
ReplyDeletewhats your thoughts on how to group modules within these processes? going across cores/processes has a performance penalty, even more so, if the number of proceses exceeds numbers of core.
so Im assuming some kind of grouping of modules into a process is necessary...
e.g. in something like BWS, afaik, only the VSTs are grouped into processes (configurable). the main daw runs in one process.
I guess an ideal architecture, would allow distribution of modules across processes, but that gets complex quickly, as the data flow between different modules is very different.
( I think limiting to VSTs makes it easier, is just audio/midi and automation... but even that is far from trivial :) )
Mark Harris have you read what I outlined in the readme? I think it outlines my thoughts on this.
ReplyDeletesorry, read it a while ago .. its pretty clear now, especially having checked most recent code :)
ReplyDeleteI guess therefore the main interaction, is having the layout defined for the SHM (i.e. meta data, midi io buffers, audio bus io buffers)
also then structuring the child audio components into a tree for processing and passing data between them (and SHM at top n tail)
Mark Harris one key part of what I'm thinking of is that none of the SHM for outside audio and MIDI is required, i.e. it's just sent for audio to the main busses but the channels can output audio directly to the sound card. I was thinking that for meta data we use the JUCE master/slave interprocess communication that's already used now to setup the audio configuration.
ReplyDeleteyup, I got that, as such in a simple setup all the work is being done in one client (with multiple components) reading its midi directly, and outputting directly to the AI.
ReplyDelete(btw: I see no reason to say a non-midi controller cannot be a child component, as long as it outputs midi, which your using as the common language )
thoughts on bus 'coordination'
say you have an instrument channel, and a reverb channel which use a bus (so shm). ok, so instrument outputs to the bus, this will mean the reverb channel will process it for the next audio buffer.
i assume we can have multiple channels feeding onto the 'same bus' (common for send effects) , so this Im assuming means the main process will 'mix' the 'same bus' channels (in different shm areas) , and then feed this into shm input bus for the reverb channel...
(I guess at the start of the next audio buffer cycle)
If this is the method, I assume the only 'lock' required, is for the master to be able to tell the child, the buffers are 'ready' ... I guess this is the 'clock sync'
Mark Harris that was exactly my reasoning about the bussing and I thought I got it to work, however it seems that this was closely related to when the children were started and how close in timing they were to the main process audio callback time. When switching to other buffer sizes and recreating the children, I realized that a child could be finished with its work right before the timeout of the main process audio callback result, meaning that gathering everything and sending it back out results in crackling. My current approach is for the busses to be always one audio buffer later (yeah, not ideal, but I couldn't thought of a better way). So the channels output straight to the audio interface and populate the SHM buffer (using double buffering), then the main process used the finished buffers to aggregate for the busses (currently this just mean outputting the audio). Now I'm struggling with a cross-platform locking approach and I think I'll have the revise the SHM method since it looks like I'm running out of allowed SHM segments on MacOSX.
ReplyDeleteMark Harris truth be told, I was hoping to do this without any cross-process locking, since this is a really bad practice in the audio thread, but even with a direct memcpy there's still a chance for a race, and I seem to be occasionally hitting that
ReplyDeleteyeah, Id suspect one buffer delay is 'inevitable' (and iirc ableton has this on return track ).
ReplyDeleteperhaps with the double buffer, a CAS approach could work.
(seems appropriate for audio, given children cannot be late!)
Mark Harris I'm starting to feel I'm out of ideas to get the SHM approach to work, on Windows it's just crackling like crazy and on macOS it works 95%. Somehow it feels like the data of the child processes are not visible to the main process in time, even with the additional locking I put in place. I'm thinking of scrapping the multiple processes approach and using near-realtime threads for the channels instead. This might also make it easier to handle the busses without introducing an additional buffer for the audio on there. Do you have experience with how OSes handle thread distribution across multiple cores? Can we rely on the OS to figure this out or should we consider using processor affinity hints?
ReplyDeleteMark Harris I have another idea to get SHM to work reliably, hopefully this will be the one, trying it out today ... :-)
ReplyDeleteprocess affinity can help (if you don't have too many processes) to be able to retain processor cache/pipeline etc.
ReplyDelete(theres other advantages about cpu memory/bus access, but that gets quite processor architecture specific)
you might want to try different 'schemes', allocating over all cores, or just a restricted set. (to allow the OS to schedule other processes on the the non 'pinned' cores)
I assume your setting the thread priority too, they will all need to RT threads etc.
It sounds like your have a scheduling issue, since your clients processors are currently virtually doing nothing...(say compared to a VST) ... i.e. they create one buffer then go to sleep , no?
(btw: do the client processes also run, the VST UI eventually, if so they will need to have a non-RT thread too for that)
let me know how your 'new idea' goes...
if you decide to go to a single process, leave this code around (perhaps separate branch) , and I'll also have a look. unfortunately (of dev time ;)) Ive got guests arriving today, so will have to grab time where I can find it.
also, even if you go to a single process, keep the 'architecture' the same, such that the communicate between 'main processor' and channel is an implementation detail. this way multiprocess could be 'revisited'. also you may find the scheduling issue doesn't disappear, i.e. the shm is no par se the problem.
anyway, Im sure your on top of it by now :)
Mark Harris seems that this new idea made things a lot better, there's still one case I identified where when launching the clients they could be in a really unfortunate state, making it virtually impossible to get the buffer in time. My plan for this is to not start the audio right after each client's startup, but to send the message for that only at he beginning of the main process' audio callback. That should much better synchronize the coordination of the audio callbacks of the children.
ReplyDeleteGreat question Geert. I had to really think about it. As a relatively new user (about a year), I initially played with everything a lot, and was fascinated with all the possibilities of EigenD and all the agents and belcanto, and raved about them.
ReplyDeleteAs the year went on, I was using them less and less without really thinking about it. Happy they were there, but avoiding them, finding workarounds, and stripping down to now running midi or osc setups from a pi, each step just for practical reasons, laziness or to solve a problem.
This is the first time I really thought about it. In my head I kinda had a picture that I was still using them more than I do. Like someone keeping a closet full of old clothes that they "might" wear again. I can't even use the convolution / cello on my portable setup due to lack of RAM.
Yes, I think that you're on to something.
I also have to admit that I hate EigenD from a practical standpoint. I absolutely love the idea, and am amazed at what it can do in principle every time I open it, but find the UI next to unuseable. Not that I can think of something better, I see the logic behind it, but even as a coder, it took me 4 hours to figure out how to create a simple midi rig that allowed me to change channels from a button group.
I loved belcanto at first, but as eigend evolved I couldn't use it anymore because the Tau setups demand that commander be running to accept it, and commander stopped working due to some issue with later wxWidgets that proved intractable to solve.
The drummer/metronome agent is useful, only in a standalone setup. It doesn't sync with other gear, which means I mostly don't use it. I looked at Link, but got lost trying to implement it in eigend.
Arranger doesn't support critical sequencer features like gate time, so I never really found it useful. I looked into the code to see if I could implement it, but realized the amount of work involved to make it play nice, and put it aside.
and EigenD frankly takes far too long to load a setup should something go wrong live. I've had it happen. Roady tripped on the cable, and well... The standard Tau setup takes several minutes to load, and most of it is features I don't need, which is why I started stripping things down, but even then, it can take 30 seconds, which live is awkward. Don't get me wrong - I totally understand why, and the complexity of what it has to do, but there is the core issue - complexity. It's trying to be all things to all people.
A new approach is a fantastic idea.
I feel that may be more critical than I intended it to be. I am amazed and constantly delighted by discovering something new EigenD can do that I'd never expected. It's an astounding piece of work.
ReplyDeleteAnswering your question honestly however, there is so much that I don't use, not because of any defect, rather more a consequence of it's complexity and depth. You can do nearly anything with it, but the consequence of that is a technical complexity and learning curve that is likely beyond what most users can cope with.
I'd like to help in any way I can if you move forward with this idea. I'm somewhat at a loss on how to address some of the issues I discuss, because as I said, I can see the inexorable logic and necessity behind what we have already, but on a practical level, it's problematic.
I think in some ways your right Kim McCann , the flexibility in EigenD, creates a lot of complexity... perhaps too much for many/some users, especially as there are very limited resources to learn EigenD.
ReplyDeleteSo I welcome simpler alternatives, be it HEELP or MEC, or whatever... choice is important I think!
Within MEC, Ive also released 'EigenFreeD' this is a simple API than can be used with any application you want... e.g. I created a max external for using it.
Im sure I'll me using MEC/HEELP day to day, for its simplicity, which often is all I need... and Im sure for many it will be a thankful alternative.
However, some reading this may be 'concerned' EigenD is going to vanish, this is NOT the case.
I still think EigenD is something very special in the 'music software' world, it goes beyond many other tools with its modularity, it scripting (belcanto), and remote interfacing... even without an Eigenharp, its a fantastic piece of software!
SO... Im not going to let it die, in fact the opposite, I plan to stabilise it, and then move it forward.
as time passes, my familiarity with the code base increases, e.g. only last week, I created first 'remote' juce app, that can communicate with EigenD... I'll let you guess why i was experimenting with this ;)
perhaps is just me, but I like the challenge of EigenD, its keeps my 'mind' sharp, trying to understand its code base ;)
long live HEELP, long live EigenD , long live EIgenharps ;)
My 2¢ as a new ’harp user.
ReplyDeleteLoving my Eigenharp Pico. It literally is a dream come true. So much so that it gives me a deep sense of quiet, like reaching a life goal. Not kidding!
(Blogged about it but my blog is down.)
But while the instrument is awesome, the EigenD situation is a real issue.
Even before getting my Pico, was really hoping there could be basic software to make it into a “simple” MPE controller. Sounds like the Pico restrictions are even deeper than first imagined. But the dream lives on.
At this point in time, the “onboarding experience” of getting an Eigenharp to work for the first time can be rather daunting. The installation process on a current Mac can be remarkably painful because of security features introduced a few years ago. And since everything has changed so much since the documentation was built, it’s quite confusing.
Let’s just say that it’s not instant gratification.
Have yet to try ROLI’s hardware products but it sounds pretty clear that their strategy is working. You may say their instruments are limited but they’re clearly having an impact in the scene. The last two episodes of Sonic State (before and after the Seaboard Block announcement) are quite representative of that.
Thing about those devices is that they’re easy to integrate in existing setups, including on iOS. AFAICT, they can be pretty much “plug and play”, even in Bluetooth MIDI (so, without “plugs”). Sounds too good to be true and there might be issues with pairing. But there’s something incredibly compelling about connecting a controller to an existing setup and having it work right away.
Before the Seaboard Block, reactions to the Blocks line were mitigated. But MPE is gaining traction and ROLI is part of this.
The Seaboard Block is actually what made me search for breath-friendly alternatives and find out about the Eigenharp.
So, the “pie in the sky” dream would be having the Eigenharp line work a bit more like ROLI’s devices. Might be completely impractical in the current state of things, but dreams do help break some circular thinking.
If EigenD didn’t exist, what would we invent instead? Probably something really minimal which, somehow, “converts the signal” from any Eigenharp into something as standard as MIDI. It probably wouldn’t include any hosting feature, since there are so many hosts out there. The cello and clarinet models wouldn’t be included because they’re hard to imagine outside of the EigenD model. There probably wouldn’t be a looper or even a way to change scales. Assigning different controls would be done elsewhere, say with MIDI Learn.
Hopefully, this magical piece of software would run on just about anything.
Bear in mind that we wouldn’t know what we’re missing. We’d just have an amazingly expressive instrument at our disposal. In the Pico’s case, it’d be one of the most compact setups imaginable.