dontletmedrown

SONARtist

bitflipper


All good ideas, jm24. But this one

track templates WITH data: audio and midi

elicited a "huh?" response. I can see possible applications of having some preloaded MIDI, perhaps to initialize some synth parameters. But I can't think of any reason to have audio attached to a track template. What's the scenario you're thinking of?

jm24, these are also real great ideas, and like bit I would support all of them.  The track templates WITH audio and midi data "issue" that bitflipper has brought up (and probably many would also think similarly) can be easily resolved by having the option to include or exclude audio and/or midi data when exporting / saving. 

Or am I wrong ?

Nope you're not wrong, but it should be associated with a session, not just individual tracks.  The most common use is to get your drums dialed in one session, then painlessly copy all those settings into another session that already has [different] audio.  I think the only time you would want the audio to come along for the ride is if you're trying to rebuild a corrupt session.

Okay, but isn't a "select all" (tracks, busses, routings, etc.) equal to a session ?  I think we want the same, i.e. the ability to export a "session", which may or may not include audio and/or midi data (selectable).  The session can contain as many tracks / busses etc. as we like ...

SONARtist

bitflipper


All good ideas, jm24. But this one

track templates WITH data: audio and midi

elicited a "huh?" response. I can see possible applications of having some preloaded MIDI, perhaps to initialize some synth parameters. But I can't think of any reason to have audio attached to a track template. What's the scenario you're thinking of?

jm24, these are also real great ideas, and like bit I would support all of them.  The track templates WITH audio and midi data "issue" that bitflipper has brought up (and probably many would also think similarly) can be easily resolved by having the option to include or exclude audio and/or midi data when exporting / saving. 
 

I didn't respond to the original idea because it is covered by the "Import Project Data" feature we proposed. I will address the question here because it relates to that feature. (It is just called differently).

The big difference between Importing Project data and Exporting/saving is that for the latter you need to first open the project where the data is and then export it, return to the project you were in, import the data. Not exactly a scenario that fits in this workflow related thread. ;)

The other big difference is that you can't export a sequence. You can bounce audio but then you loose all the edits. If you accidentally cut of the first transient of a drum hit or the first syllable of a word or whatever, if bounced and exported, you can't retrieve it. If you have the original track as it was edited, all you need to do is drag back the beginning of the relevant clip to retrieve the section you had accidentally cut off.

If you can "Import Data from Project" You have direct access to that track. You can import it straight into your current project. You don't have to open the other project at all. You select Import Data from Project from a menu. Browse to the relevant project and Sonar shows you a list of tracks and buses in that project. You can then select a number of tracks and buses to import and you can select what type of data you import for those tracks/buses. Clips, envelopes, I/O, Sends etc. You can also select whether the imported data goes to existing tracks or to new tracks. You can determine whether it remains at the original timecode/musical time or whtether it gets shifted to a new time location. Etc.

I can give a dozen examples of how I use "Import Session Data" in Tools in audio post work. One example would be getting a new version OMF of the video edit of a scene or a TV show or whatever. While the video editors where busy, I recorded a Voice Over and edited so that it was clear of breaths, mouth pops, ticks etc and aligned everything to picture.

I create a new project with the newly edited video and audio. All I need to do is "Import Session Data" to import the VO track from the other session. I might have to move things about a bit to match the new video edit but it is still much more flexible than bouncing the VO from the previous session (which removes the ability to change any edits. Not in anyway a desirable situation!).

Once people have this type of flexibility in their DAW, they will automatically come up with ways to use and abuse it. :)

UnderTow

Thank yous guys for the feedback.
 
Current Example:
 
I have a project with 4 variations of the percussion: midi and audio tracks
 
I want to:
 export ONLY the percussion tracks/ effects/ vopes/ routings,...  from each project
 create a new project
 import the 4 percussion variations
 And continue on.............
 
I understand I am attempting to sorta nose-under-the-tent of project workflow with this particular desire. But, it is very difficult to copy/paste/duplicate 20+ tracks of data, routing,.... from 4 projects into one. So, this is a description of a tool that would enhance creative flow.
 
(And I am using every opportunity to list my wants.)
 
J
 
---------------------------------------
 
Testes:
 
reproductive organs outside of the body, exposed to easy injury
 
so, those more able to defend the ability to reproduce will be those to reproduce
 
unfortunately such ability is not always a reflection of intellect
 
hence, the large percentage of the population that does not possess a first language
 

If they made the track templates apply to existing tracks that may be all that is needed. Track templates as is are not all that useful but if they could do that they would be.

John

If they made the track templates apply to existing tracks that may be all that is needed. Track templates as is are not all that useful but if they could do that they would be.

You mean like pick a style (template) and apply it to a track selection? If that's what you mean I like the idea of that.

John


Well I don't know what style means but I like it anyway. I was thinking that a track template with its plugins should be applied to a a track then that track would take on the settings and all plugins that are in the template.

Yes, this would definitely do the trick.  It should also apply track templates to all selected tracks too. 
 
That way you could apply the same track template to several tracks if needed/desired.
 
I like, I like :-)
 
 
 

John

Well I don't know what style means but I like it anyway. I was thinking that a track template with its plugins should be applied to a a track then that track would take on the settings and all plugins that are in the template.

Yes we're on the same page.  Just terms at this point in the discussion.  So .. a bit further ...what about ..

select a track
copy settings or save settings as template (whichever you prefer)

select tracks
paste settings
or apply template

Amazed

John

Well I don't know what style means but I like it anyway. I was thinking that a track template with its plugins should be applied to a a track then that track would take on the settings and all plugins that are in the template.

Yes we're on the same page.  Just terms at this point in the discussion.  So .. a bit further ...what about ..

select a track
copy settings or save settings as template (whichever you prefer)

select tracks
paste settings
or apply template

Exactly what I had in mind. You can be on the idea team too. LOL

Oh John, you say the sweetest things! :D:D:D

Thanks Dave, I've never had the chance too see this. So it can do a merge or complete replace of your current session?

EDIT: I'm a moron

removed because far removed from topic. sorry.

Just an observation I have made, since this process for a unified voice of participants has jelled, I have sensed a significant improvement in the morale and demeanor of all forum communications.  I am seeing more patience in replies and generally a more helpful attitude.(I don't think I have seen a RTFM reply for over a week)

Its as if a sense of empowerment this process is developing as a side effect of the discussions and contributions.  Although we all differ in what and how we go about doing our music we are all bound together by the common bond of trying to get that wonderful music we have floating around in our heads expressed in a tangible manner in as efficient and effective a manner as possible.  The sense of community that this forum and Cakewalk products we use provides has been improved dramatically by this process.

We have a common bond with fellow users as well as the company to achieve our goal of producing what we love, and that is our music.  Our success in achieving that goal more efficiently  is directly related to the success of the company in meeting those objectives.   The more successful they are the happier we will be as their customers.

I believe the byproduct of this process has been to make one of the best and most helpful forums around get even better.  I thank the originators of this concept and all the participants for their persistence and effort  in  moving  this along  and as  a  result  we  have all benefited already; and that is before we even see any response or action on behalf of Cakewalk.  It can only get better.

Lorne
 

glazfolk


There are some very worthy ideas included in the top ten wish list.

I'd like to raise a point, though, that as far as I can see no-one else has. If I'm wrong and have missed this, please forgive me.

Let's say that Cake agree with the bulk of these requests and take them on board. Unless they also change their current development philosophy nobody will know until Sonar 9 (or whatever it's called) is released (say) another 12 months from now. That's because up to  now it's been their policy to keep the contents of each next release under the strictest of wraps until the last minute.

In the context of entering into some sort of dialog with the people making this request it seems to me that continuing this policy of secrecy just wouldn't make sense. I mean it wouldn't progress matter very far if they were to say, "Thanks, we've read this, we've decided how we're going to respond, but we're not going to tell you."

I'd say that in making this request, therefore, you are also by implication asking Cakewalk to ditch this policy and share with its user base at least in part its future development plans.

Personally I think that many would welcome this, but whether that's the case or not it's an issue, I think, that can't be ignored. I'm not sure it's how the company wants to go.

I can not speak for anyone else, but I agree with your interpretation, Glazfolk. There is a major assumption/implication built into that list, and some fluctuating mix of both hope and expectation.

Marah

glazfolk


There are some very worthy ideas included in the top ten wish list.

I'd like to raise a point, though, that as far as I can see no-one else has. If I'm wrong and have missed this, please forgive me.

Let's say that Cake agree with the bulk of these requests and take them on board. Unless they also change their current development philosophy nobody will know until Sonar 9 (or whatever it's called) is released (say) another 12 months from now. That's because up to  now it's been their policy to keep the contents of each next release under the strictest of wraps until the last minute.

In the context of entering into some sort of dialog with the people making this request it seems to me that continuing this policy of secrecy just wouldn't make sense. I mean it wouldn't progress matter very far if they were to say, "Thanks, we've read this, we've decided how we're going to respond, but we're not going to tell you."

I'd say that in making this request, therefore, you are also by implication asking Cakewalk to ditch this policy and share with its user base at least in part its future development plans.

Personally I think that many would welcome this, but whether that's the case or not it's an issue, I think, that can't be ignored. I'm not sure it's how the company wants to go.

I can not speak for anyone else, but I agree with your interpretation, Glazfolk. There is a major assumption/implication built into that list, and some fluctuating mix of both hope and expectation.

Which is why, as well as a 'public' bug tracker, for registered users, we need one of these: http://brainstorm.ubuntu.com/ this thread is nice an' all but it's positively arcane compared to the brainstorm tool.

Child