Anderton
[To quantify, I think a lot of the newer paradigms are oriented toward composers, while programs like SONAR, Pro Tools, etc. have their roots with players.

Anderton
To add to my comment, I feel SONAR excels at songwriting, which to me is different from traditional composition. With the latest SONAR updates, it's never been easier for me to create songs efficiently...far more so than writing on guitar or piano, which I never thought would happen when using a computer.

Anderton

candlesayshi

Anderton
To add to my comment, I feel SONAR excels at songwriting, which to me is different from traditional composition. With the latest SONAR updates, it's never been easier for me to create songs efficiently...far more so than writing on guitar or piano, which I never thought would happen when using a computer.

Seems like it's probably either another "different strokes for different folks" situation, or perhaps just a difference in how we define things to ourselves... because it doesn't come across that way for me at all. I feel that SONAR is excellent at production, but trips over itself when it comes to songwriting as there's very little about working in it that is immediate. So, writing songs in it becomes more of a hurdle race for me. Rather than the flowing state that it should be.

The workshop I've done at NAMM, GearFest, and AES on "Songwriting with Computers" is based on SONAR, and being edited. It will be posted on the Harmony Central YouTube channel sometime in the next few weeks. It may include tips you find helpful. But I'm not using staff to do this, I'm writing with instruments.

trtzbass
Are we enabling the developers to use their best judgement or do we make them feel like they need to give us something every month just to keep faithful to their pledge?

trtzbass
Hey, thanks you all for participating to this thread.
Even tho I admit I don't know how software developement works, I am ceratinly not picturing the bakers scratching their head month to month trying to come up with something to put on the plate.
I evidently have not expressed clearly enough because no one got the main reason behind my post (not considering the exchange I had with Craig Anderton that was more personal and centered on my preferences).
 
Let me rephrase:
Are we, as the user base, allowing the bakers to do their job in the best way possible?
In the last days before the release of the new early access I noticed a lot of questioning in a few threads, with people inquiring about the date of release of the update. Quite a bit of speculation, a touch of inquisitive attitudes here and there. If I put myelf in the shoes of a developer I would perceive that as pressure.
Hence my question: is our attitude towards the monthly releases conducive to good work? I myself must have refreshed the forum main page like forty times in the impatience of seeing the early access, er, accessible.
Could it be that all that scrutiny on release dates and alleged skipped months has an effect on how the bakers structure the releases?
How would we react if the bakers decided to skip a month for some reason like (knock on wood) unexpected last - second instability or because they'd redirect the efforts to complete a critical update?
Are we enabling the developers to use their best judgement or do we make them feel like they need to give us something every month just to keep faithful to their pledge?
Am I making more sense?

35mm
To the OP,
 
I don't think you understand how software development works. You seem to be under the impression that the bakers are scrabbling around all month trying to come up with that month's update. That isn't the case. They use a versioning system such as git, which uses branches. One of those branches is the production branch which is what you end up using, but there is also a master branch and lots of development branches coming off that. What gets released in the production branch at the end of the month is a culmination of stuff that's been in development and testing for months. Behind the scenes, developers will be working on all sorts of stuff, trying out new ideas many of which may never see the light of day, fixing bugs etc.
 
Something else that modern software companies use is an agile development method e.g. scrum. That's too complicated to go into here, but in essence, it involves splitting everything into manageable chunks, assigning each chunk to a developer and assigning a time span to that. Then holding regular meetings to assess the progress of each thing. This all breaks down to make everything manageable and highly productive. And here's the big thing. A monthly release fits into the agile method perfectly! So monthly releases are so much more efficient all round and result in much higher quality.
 
Monthly releases are also more efficient for us users for similar reasons. It means that we don't have to cope with getting our heads around a major new release that suddenly changes the whole landscape and has to be re-learned all in one go. Instead, we get bite size changes each month which are far easier to understand and integrate into our workflows. If a release introduces a new bug, that bug can be fixed and rolled out much quicker without having to wait a year for the next major release or fiddling about with messy patches.
 
There are users who dislike the monthly release model, but perhaps if they understood a little about software development they would understand that it is a much better system all round. It's worth remembering that much of the Sonar you will be using in June 2018 exists in a branch now that bakers have access to and that makes our current version of Sonar look dated! They are constantly working in the future so that we can be up to date today and monthly releases mean that we are even more up to date - by about 11 months!

The beauty of the monthly updates.......they are all voluntary.