Posted
Hey Hey,
After reading the post with duplicate track request I thought it would be good to suggest an Action list, akin to reapers.
Reaper is 5mb total and has gigantic action list; there is no bloat associated with those kinds of functions as far as I can tell.
It seems every feature request here is met with an argument. As many of us report struggles in making Synfire work smoothly, it would seem best to give us options instead of meditating in the hope of one day inventing a solution that will work for all of our disparate workflows.
You mentioned that if there are more than 15 features in a menu, then the developer made a mistake...
I don't use or need 90% of the functions in the menus... The developer has already made a mistake (no offense really) I'm asking you to fix it by letting us fix it. Reaper as well as all daws have the ability to customize menu's -- Reaper in particular allows, buttons, hotkeys, tool pallets, right click contexts and anything else to be customized.
As it is development of new features or workflow enhancements is glacial... Our workflow issues seem to have no chance of going away anywhere in the near future. You mentioned it would take you 5 minutes to add the duplicate track feature... It probably took more time to respond to that thread. If there was an action list where it could be integrated, only if needed, everyone could be happy.
Its is pretty much agreed that are a great number of completely different workflows here. You seem to want to meditate on the value of every feature, but from whose workflow perspective are you considering the problem from?
I do hope we are not searching for the lowest common denominator, that never turns out well.
EDIT:
Also, this is not a request for the sake of customization, it is a means to let you loosen your hesitance in implementing the things we think we need without wrecking the program with half baked ideas.
Sa., 20.03.2010 - 21:35 Permalink
I appreciate that the learning curve is steep. I have been using this software between 14 and 18 hours a day 7 days a week for 6 months and then liberally for 6 months before that. I do understand it. I have a good background in theory, classical and 20th century. I have experience in programming C++ and object oriented concepts. I make my living as a composer and have built a workflow around this software as best as I have been able.
I appreciate the uniqueness but I am greatly burdened by its weaknesses, which are not few. I am not the only one who struggles with aspects that having nothing to do with a misunderstanding of the core concept.
I find it patronizing that you would assume that our issues are simply due to a lack of understanding.
When you say you don't want this software being turned into another DAW you are being extremely vague. What does that mean?
If you look at reapers Action none of them have anything to do with the kind of DAW bloat that is often criticized... It has nothing to do with built in EQ's Comps Synths or effects.
The actions we are talking about are akin to, inverting a segment or reversing a span selection. Simple data manipulations to keep us for having to labor over extremely redundant processes.
What I am suggesting is a system of implementation that will keep the people who are afraid of development and new features comfortable and even let them disable what they don't want as needed; it will also free the developers to address the issues that arise for the rest of us.
The whole point of this feature is that it is a conceit to your own concerns in minimizing bloat, while letting progress continue in spite of your fears of its failure.
Synfires steep learning curve doesn't necessarily need to be, it only is because it is new and untested. The hope is that our hands on experience and struggles will reveal methods to simplify the approach.
So., 21.03.2010 - 01:58 Permalink
tokyorose I bow to your skills... my comments weren't directed at you and I didnt mean to belittle your skills in any way.
I dont want a another daw with tracks where i edit/record a track at a time, copy and paste sections around to make completed tracks. Im sure you have used a normal daw, you must have an idea of what im talking about.
I struggled in fact still struggle with synfires way of doing things compared to sonar (which i also own), but i am more creative/productive using it. I agree with you that there are several things which it makes hard to do, several areas that seem buggy but many things it simplifies.
I use a hardware synth based sequencer as my final target and even with the synfire->sonar->sequencer workflow i am forced to use due to limitations/bugs in all three areas, I am still more productive than without synfire.
Im sorry I cant really put into words what I am trying to say about synfire not becoming a normal daw, but I hope you understand some of my concerns, and also accept that I didnt mean any slight of you.
PS
if you let me know you have read this post Ill remove it so as not to cloud your topic (or a moderator can)
So., 21.03.2010 - 19:15 Permalink
Hey hey,
No need to remove anything or bow.
I just wanted to make sure this particular issue stays clear and is not classified with bloat or misunderstanding without a clear reason as to why.
If its technically feasible and easy to implement, it would be a good way to speed up the testing of new ideas and workflows for those of us willing to be the guinea pigs.
Here are some examples of things im thinking of...
-Stretch container %50
-Fill transpose and variation with 0 on selected tracks
--- this lets you lock down variation on drums and static melodies (that relate to audio data) while applying a global variation and transpose to a container
-Select all with same articulation
-randomize articulations
-Reduce all velocities breath and vol data by %15
-divide container at harmonic modulations
-transpose arrangement
--- this would adjust harmony but playing ranges of all harmonic instruments as well
-extend phrases of all instruments to the end of the container
-Duplicate all properties except figure and take to all selected tracks (this would use the last selected track as the template)
--- This would let you fill all your default volumes and pans and properties for different sample libraries
-turn off looping for all selected instruments
-stamp segment
--- This would insert a copy of a selected segment at the anchor of every segment of an instrument... So you could take a simple melody and make each note become an ornament offset bey the anchor position.
-thin and tighten rhythm
--- this would delete symbols that are alone and not accompanied by another instrument or note on that beat.
I could rattle these off all day. As it it is all of this things require lots and lots of repetitive work no matter how well one understands the concept of Synfire.
All of them seem like they would involve minimal code and no gui, or at most a small simple standard dialog box
Mo., 22.03.2010 - 01:26 Permalink
@tokyorose-I cannot agree with you more. The addition of such functionality is absolutely NOT tantamount to bloating a software.
Anything you add to a software that increases your productivity and helps you do things better and faster with EXISTING FEATURES is not bloat!
If Cognitone starts adding compressors, EQs, and synths, that would be bloat.
Synfire is an amazing program. I welcome anything that helps it be more USABLE!
Mo., 22.03.2010 - 18:37 Permalink
- Assignable key commands.
I jump between Macs at work and PCs at home. But all my software, Cubase, Nuendo, Final Cut Pro, Premiere, allow me to set up similar key commands for basic navigation and often used features. Just can't get used to Alt + Home for zooming in. I much prefer +.
(BTW, what is the key command for jumping to the start of a song.)
I agree this is not a DAW at all, I wouldn't want it to be. It is unique. In fact Cubase sits behind this until I'm ready to dump my data into it to clean it up. Just looking to make Synfire a little easier to cruise around in.
Mo., 22.03.2010 - 20:05 Permalink
I just thought of two more that would really be helping right now.
-Strip Vol/Pan/Reverb from clipboard data
-Average volumes and replace in selected containers
---I often have many volumes set in short containers, I set them as loud as I need to record, but unless I create them in chronological order, or make sure to absolutely fill every container with a volume, problems can arise between my record mix and my mix. This would quickly capture the general volume, fill all containers and let us fine tune level with vel and other real dynamics controls.
Would any one mind me starting a thread specifically and only for listing these sorts of minimal functions? Particular ideas could be discussed in separate threads
Mo., 22.03.2010 - 20:11 Permalink
Would any one mind me starting a thread specifically and only for listing these sorts of minimal functions? Particular ideas could be discussed in separate threads
That's a great idea. It would be cool to keep a running list at the top post of that thread?
Mo., 22.03.2010 - 20:23 Permalink
(BTW, what is the key command for jumping to the start of a song.)
I don't know of one, but I put in a request for one a while back:
(https://users.cognitone.com/node/1694)
Here's another goody:
Mo., 22.03.2010 - 21:27 Permalink
First off, I'd like to say that I much appreciate this discussion. A sticky thread with a list of desired "commands" and another for frequently used workflows is highly welcome. We need this information to base our decisions on.
Action lists and customizable key commands roughly fall into the same category. A key command editor already is on our agenda.
While it is relatively straightforward to implement this sort of convenience, the real challenge is to identify the set of commands. I'll demonstrate that with a very simple example. Let's assume the action
"Delete all figure segments in the root container"
was a useful thing (which it certainly isn't). While it might appear convenient to have some hotkey or menu item for it, it could also be accomplished by
- Select root container
- Select Figure parameter
- Select all
- Delete
Each of these four "primitive" commands is universal and serves countless other purposes, considering the many ways in which they can be combined. The design goal is to identify the minimum set of primitives that, when combined, allow for the maximum transitive set of useful actions. That said, using the four primitives is better than adding a new command that combines them.
Why? The answer is simple: Because this allows a user to figure out new workflows on his own, depending on how flexible the primitives can be combined.
The example is trivial. However, the task gets tricky when primitives are involved that are yet unknown ;-) That is, if some new demand pops up for a feature, my job as an architect is to figure out whether that feature could be combined from existing and potential new primitives. In order to ensure best reusability and effectiveness of new primitives, I need as many workflow and feature suggestions as I can get.
Talking about actions, another thing to consider is: The objects in a DAW are much simpler to address, as they are usually static (midi, audio) and flat and can be enumerated. Synfire's objects are hierarchically structured and not referenced by numbers and there are many different types of vector data, some of which are deeply structured too (hey, did you know containers are vectors of containers?). Addressing the right object in an action or script could be cumbersome.
EDIT: My original use of the term "bloat" didnt refer to feature bloat, but rather literally to the high number of long and verbose menu items in Reaper that required me to read and decipher them all rather than relying on intuition.
Mo., 22.03.2010 - 22:14 Permalink
The example you give can be accomplished in fours steps; that is rare.
The issues we are discussing instead take 20, 40, 90, 400 steps -- Over and over again.
It seems you are suggesting that the goal of the tool set is to be as concise as possible... Usefulness should be the guiding rule, not concision... I appreciate that 'select' is a low level action, but I dont want to do it 200 times every two hours. We're making music not building bridges.
The short term is important too. You have people relying on the software now.
Are the kinds of actions we're suggesting possible to develop in Synfire, by any means? I understand if the ultimate implementation uses macros, scripting etc -- as long as you're doing the programming it doesn't concern me.
Are you saying that these features are not technically achievable at all? Please explain specifically which and where.
If the answer is no and they are achievable, do you recognize the explicit need for all of the specific actions I listed -- being that none of them are even close to requiring 4 simple actions. -- Again these solutions could be scripts or macros if that is something that is not years off.
Of course there are going to be things that aren't covered by primitives... Like the strip vol/pan from clip board action i suggested.
The main question is -- At what point can we expect workflow issues to be addressed in a rapid manner? All evidence indicates, that when you suggest thinking about the most precise way to approach workflow issues, absolutely nothing happens.
Dead simple cut / pastes issues that many of us have had issue with have lingered for eight months. Yet, we had both, redo and the new segment-resize-drag resize tools within a day or two... If these are indeed two different approaches i would be much happier if you indulged the latter.
I don't sense that the beginning of an end to these issues is near. Am i wrong?
Di., 23.03.2010 - 00:48 Permalink
What about introducing a macro type language even a simple one. Then end users can work out their workflow requirements and craft macros out of the primitives you mention andre. Then if the workflow requirements still cant be achieved then it can be raised as a development request and if felt worthwhile the synfire team can develop it and add the new primitives.
We could even end up with a user generated library of macros a bit like the collection of CAL scripts for sonar.
Add to that customisable key and menu bindings and Im sure a lot of people would be happy.
Di., 23.03.2010 - 01:05 Permalink
@tokyorose:
I'll comment on your suggested actions in detail in the other thread. Let me first explain why sustainable feature development is such a mission critical thing.
It's not that usefulness and concision are opposites. In fact, usefulness requires a certain level of concision in order to make features accessible to everyone. Otherwise the requested features will be mainly useful to a single user only -- the one who requested them.
The quick and dirty addition of features leads to usability problems and serious engineering trouble in the long term, because once a feature is there and is being actively used, it can not be removed anymore. That means: Every step we make, we make it forever.
As a result, with an increasing number of ad-hoc features, there is less room left for design improvements and true functionality enhancements. Eventually this can lead to a situation where a product gets stuck and the only way to improve it is to abandon it and start a new one from scratch.
Redo was quick, because it's just programming, didn't require any reasoning about its function or long term usefulness, and the underpinnings needed for it were already there.
The reason why seemingly simple issues can take a lot longer is that usually many of them are related to each other and require a more general overhaul of the groundwork behind. That is, you will likely see a bunch of them resolved in one go, once we got around to reworking the underpinnings. Multi-selection and triple-state capability of form widgets is an example for this.
I am doing software engineering since 25 years. Rest assured things are in good hands ;-)
You might have already seen there's a new sticky thread for micro workflow features. I also posted my reply to your individual suggestions there (along with a copy of your list).
Di., 23.03.2010 - 01:16 Permalink
@blacksun:
As addressing objects in Synfire is far more complex than in a DAW, scripting would require a rather comprehensive language framework. I don't see that in the mid term.
We rather want to provide the necessary built-in functionality needed to make Synfire optimally usable for the majority of use cases.
That said, do not hesitate to add you own micro workflows to the list ... the more input we get, the better.