Is there any way to edit MIDI controls with parabolic curves? (line that can be bent)
So the data would simply be sent whenever the value jumps to another integer.
That is really a need for me unfortunately. I cannot use Ardour without this
florianb: the lines you see drawn are NOT the data that is sent if you opt for ācontinuousā mode in the CC/automation track/lane. The ādiscreteā mode sends only the events/nodes shown, but ācontinuousā interpolates with smooth curves. It just so happens that the lines draw donāt indicate this. This will change in the next āminorā (as opposed to micro/bugfix) release of Ardour, where actual curves will be drawn. You should focus on editing the nodes/events for now, and ignore the lines.
Thanks Paul for your answer.
Iām also glad you are the one answering, proving once more how awesome you are
Unfortunately I cannot use events directly because I would need too many of them, about 100 events for each note⦠Mostly volume for envelope control or orchestral banks sent to LinuxSampler.
I really the curves to be the editable thing, and the events to become slaves of it, generated by them in the background while playing, and even invisible in the interface⦠see what I mean?
Making a good orchestral sound without real graphs is just too much work struggling with tones of events.
That would be a really wonderful thing and I would run for Ardour!
Paul, what donation would be enough for you to build this feature?
So to summarize:
-> MIDI volume control would be a graph that can be bent to create concave or convex lines.
-> We could move the start and end points of the line, and grab the line anywhere in the middle to give it more or less convexity/concavity.
-> Ideally, if we grab the line closer to its end, the center of the convexity/concavity is not in the middle of the line.
-> The data sent is āinvisibleā on the graph in this mode. The software would simply send data when itās time to because the current rounded value has changed (+ or - 1 step on the 128 scale)
-> (of course, if this is implemented for volume, other controllers can have it too).
Honestly Paul, I just cannot work without this feature. This is really a must for violins, it gives the ability to intuitively and quickly edit the dynamic of expression below each note.
Just let me know how much time/money it would take to build it (for everyone) and Iāll make my best to be generous.
THANKS!
Well, first of all, work on MIDI will (re)start after the release of the next (minor) version of Ardour (which will have a completely new graphics engine for the editor, and will run on windows). There are LOTS of things to fix with MIDI before contemplating significant new features.
That said, it is clear that we do need to develop much more sophisticated tool(s) to manage MIDI velocity and probably other controllers also. The work involved in this is hard to estimate, but I suspect that it is a minimum of a weekās worth of full time development, and possibly as much as a month.
t0bY: Linux is a vastly superior platform for development (particularly cross-platform development). I donāt that changing. However, a new commercial partnership does mean that there will be developers working on the codebase whose primary focus will not be linux.
i guess i was hinting at a windows platform having the obvious advantage of catching the free gpl-code-overspray whenever it wants, fusing it and making it compatible with proprietary code and creating a rather unbalanced competition.
Is there any incentive for code sharing, or keeping ardour on linux platforms competitive with a windows port? How do you reason? (hope iām not getting too deep here)
Thank you Paul.
So when you say āand will run on windowsā, you mean it will not be the same on Linux???
Paul, the whole point of Ardour is that it is very optimized for Linux for the best performance, the real and only open world.
Iām sorry, itās not really āmyā project, but focusing on Windows would make that wonderful program a crap I think.
Maybe Iām a dreamer, but I would change the world rather than changing Ardour if it was entirely my project.
Also, Iām not sure people who invested in this project would like to see a focus on Windows development. It sounds a bit like a falling angel story.
Iāve been following & supporting Ardour since almost its beginning and I will not like that at all.
the codebase for ardour on all platforms is the same. there are not 3 different branches. right now, the windows branch exists in git merely while the people working on the windows issues get test things and get them worked out. in the relatively near future, this will be merged back into the āmasterā branch and there will be no separate windows branch, just as there is no separate OS X branch.
i have no plans to any notable on the windows branch. i do not even currently plan to release Ardour for windows.
in terms of investment, keep in mind that Google already āinvestedā in a windows port, and the new commercial partnership that is forming right now has probably already invested a notable fraction of Ardourās total revenue generation in getting their project off the ground. that is not to mention Harrison, whose Mixbus sales also help fund Ardour development, and for whom Windows is a much more important platform than Linux in terms of sales. so i think it is unwise to make too many quick summaries of who the āpeople who invested in this projectā are.
actually most of the people visiting here only see the donation and subscription counter and by chance see the mention of mixbus. the idea that other lobbys bigger than microsoft invest in ardour development only becomes clear, if this is obviously stated.
threrfore i can also understand the alienation, if the general mood is that ardour development is community driven (as the button signifies), and quietly google takes the wheel and practically turns crowdfunding into a joke.
i guess there is nothing to be done now, but i would certainly shed a tear, if something like windour 16.x. is released this year and sold for dumping prices, while linux-ardour is still struggling to address the roadmap.
However, if I understand correctly, the code is somewhat shared in one branch, so ardour for linux might also benefit codewise from a windows port.
t0by, i think you are dramatically mis-representing or misunderstanding what i said.
Iāve just told you that I have no plans to work on windows specific code, or to release Ardour for windows. Iām really not sure what more you want. Googleās involvement was years ago, for one GSoC project.
But ātuningā the master branch to make it work for Windows wonāt make the code heavier?
Linux and Windows are 2 very different architectures, I donāt see how that could happen without an impact on the performance.
this is not what i meant at all. first, i ādo not want moreā. and for the record, i got it perfectly that you are not messing with windows and not plan to. i am also grateful, that you want to keep ardour dev in one branch.
i apologize, but your mentioning of an upcoming windows release together with google support seemed so damn close together that it appeared that the current windows branch has an ongoing sponsor. on this site was no information whatsoever about this, so alarm bells started going off. besides, naming goolge together with mixbus was quite irritating, as mixbus is still selling. also i was just defending florianbās apparently āunwiseā remark on the funding of the windows branch, as he seemed to have misread the whole thing the same way I did.
so again, i apologize for my misreading your lines and your patience with me (us). and i wish that ardour stays in your hands as long as possible. at the moment i am not up for a fight, therefore i hope you will accept my apologies and also accept many crowdfunders on the way
Yes, Iām just hopping no āifā will show up after compiling the binaries⦠Windows programmers are rarely good, they wouldnāt choose Windows if they were brilliant like Paul.
I hope Paul will watch/supervise carefully to make sure no crap gets in the code.
Of course no fight! Paul started an open-source project, his intentions cannot be bad! We may just not like so much this idea of Windows getting here but I bet he expected that
there is no ātuningā the codebase for windows. we use a portability layer (glib) that hides all that stuff. we donāt care about how messy windows is as long as glib provides what we need. the biggest task with the windows port was switching all the stuff that should have been done using glib but was not (we tended to use the POSIX API which is common to all unix-y systems, including OS X, but important parts of it are missing from native windows ⦠hence, glib).
there is almost no measurable impact on the performance on linux from doing this. and there will be (almost) no windows specific code in ardour, other than (potentially) in the audio backend that may show up for native (non-JACK) based use on windows.
All right, letās hope it will help you to develop this great and open project!
Please donāt forget that graph thing, that is really THE big thing missing in all other midi editors I think.
Thanks Paul.
Best.