It is a bit difficult for me to follow your thoughts, but hopefully these tips will help you:
The new instrument inspector is used to SELECT a sound only: 1. Rack Module 2. Channel. If you want to CREATE a new module by loading a plug-in, for example, you must do that on the Rack tab now. The "Edit ..." item in the menu jumps you to the respective rack.
You need a shared GM device that is playable, if you want to import a GM midi file. Therefore I suggest you create a Halion shared device first. You can copy that into an arrangement later.
You can participate simply by downloading version 1.7 from your user account, where it is listed now. Nothing else is required. Users not keen on being a lab rat should wait until the offcial 1.7 build is announced.
After installation, be sure you get the patches 1-4 in that exact order from the Help >> Online Updates menu. The patches will soon be obsolete after a new build was uploaded.
The new instrument inspector is used to SELECT a sound only: 1. Rack Module 2. Channel. If you want to CREATE a new module by loading a plug-in, for example, you must do that on the Rack tab now. The "Edit ..." item in the menu jumps you to the respective rack.
Well i studied the video where your started on the Instrument tab ..starting in the Rack tab seems to be more logical Therefore i suggest earlier ( when you start on the instrument tab : Choose Rack there and show rack type ), but that is not the case as i understand.
The new instrument inspector is used to SELECT a sound only: 1. Rack Module 2. Channel.
So after first make a rack in the rack tab i can choose a sound in the instrument tab by choosing a Rackmodule and a channel?
Can you give a warning in the instrument tab : Define first your Rack in the Rack tab and choose here the sound for your Rack ?
Why don't you divide the Instrument tab in two sections ?: two knobs to go to the Rack tab - arrangement Rack knob - shared Rack knob
Both knobs got to the RAck page and as second section in the instrument tab : assign sound to Rack
As user you start in the arrangement Tab view ..SO YOU MUST FOCUS in this screen what RACK you want to use.
Its about userfriendlyness.. the user must be get be aware that two rack types are involved..and that all soundassigninging revolves around this..must be stressed out also in the manual.
The current instrument tab gives room for misuse .... don't give the user no chance to do that..you must lead them to the right path. Do you get it ?
Make two prominent knobs on the instrument tab on the upperpart ( divive in two sections ) and the lower part label: choose sound for Rack
You need a shared GM device that is playable, if you want to import a GM midi file. Therefore I suggest you create a Halion shared device first. You can copy that into an arrangement later.
Is it not possible when i assign GM DD in a arrangement rack that it will be used as a shared GM DD for HALion5 and than it can be used by the library?
So assigning a GM DD in arrangement Rack automatically assigns a shared GM DD to Halion5 for the library..like it was in the old Synfire Express ( can this be automated ? )
Another serious problem is that Synfire goes in a busy mode ( i don't have this with Cubase ) after a sort time.. doing another task for instance on my computer brings Synfire in a busy mode and it is freezing ...nothing to do with it anymore
These two items appear in the popup menu, when the user attempts to select a device. If the desired device is not there, he goes to the "Edit ..." item. This item will receive a new name with the next update to make this more clear ("Edit Rack ..."). And I will put the shared rack on top of the menu, to make clear it is more common to use that rack first.
Is it not possible when i assign GM DD in a arrangement rack that it will be used as a shared GM DD for HALion5 and than it can be used by the library?
Only a shared device can be used by all open files and new imported files. If you create a private device, only that arrangement and its embedded library can use it. Private devices really only make sense if you use them ONLY in that arrangement. Or if you copy a shared device to the private rack (by selecting it from the menu) to MODIFY it for that one arrangement exclusively.
It seems to be not possible the other way around ?..from a private DD go to a shared DD ?
Or if you copy a shared device to the private rack (by selecting it from the menu) to MODIFY it for that one arrangement exclusively.
I ask this because when i make a arrangement rack.. than the library will be working also too, as i am used to be in the old Synfire express, but there it was shared DD i think
But the idea to load first a DD(shared) and than load again a DD (arrangement )it is not attractive, because this is the only case that this happen..or not ?
I thought this new soundassigning system was easier to use than the old one, but i am lost with the new soundassigning system for now....Synfire's GUI seems me not to help, but that is my impression.
Let other users give their experiences with the new soundassigning sytem, perhaps i must give it more attention and without less expectations ? or predominations. Perhaps i am here too rigid and hold too much on my own ideas about this soundassigninging system.
Note: i don't know now anymore to make a "shared rack"(there is no Shared rack tab) for HALion5 ( not via the Instrument tab ..that was forbidden for the arrangement rack, but it is now allowed for the a shared rack ?..that is not consistent )
From the popup menu on the instrument inspector, select "Edit Rack ...", or click the button with the toolbox icon. That will jump you to the shared rack. There you can create shared devices.
Note to all testers: A new build is online for download now. This is not a patch, that is, you need to visit your user accounts and get the download from there.
@ Andre i guess you will be very bussy in this beta test / fix period but i have to ask , - should i expect any fix or workaround solution to (my specific) DD problem to continue to use SFP as before? - anytime soon ?
i am asking this because if not , seems to me is better to switch back to 1.6.6. to bring back to life my workflow + projects for now . so shortly i can continue to work.
I've had a couple of crashes tonight. Can't remeber what I was doing the first time, but second time I had just added a new private plugin (Halion 5) to a new arrangement. I clicked the DD and it crashed. Crash reports submitted.
Let's discuss your workflow via email directly. I'll contact you. If I find a solution, I will post it here. But first I will need to fully understand what you are doing. I am confident it will work, because the new design can basically do almost anything. Your 300 DDs are not lost, that's for sure.
It's about naming and placement of items in the user interface. I wanted to note this here, so anyone who's interetsted can contribute to that discussion. Before it's too late.
It's about naming and placement of items in the user interface. I wanted to note this here, so anyone who's interetsted can contribute to that discussion. Before it's too late."
May I suggest you list the current item names under discussion for renaming, to ensure that all of the interacting items, e.g., 'shared rack,' 'private rack,' etc., are renamed as an integrated system where appropriate, as opposed to as individual items?
What primarily has been discussed in this linked thread is racks and global instruments ... but there may be some other things that could be considered.
For example, I have always considered the use of the term 'instruments' in the arrangment window confusing. To me they are 'tracks' to which various instruments can be assigned. Calling them tracks would not prevent them from being automatically renamed when an instrument sound was selected. This is not a big deal once you understand the system, but is confusing at the beginning.
This is just an example to point out that it would be helpful in considering these things to have your list of what is under consideration.
I'll put together some suggestions for the terminology so we can discuss them.
As for "tracks" vs. "instruments", there is no such thing like a track in Synfire. Tracks are linear space on a tape where you can record anything anywhere on the timeline.
The container structure of Synfire is a tree with phrases of different lengths, loop sizes, hanging at its branches, so to speak, overlapping each other, overriding each other. And all this per each parameter individually.
There is no track where you could place something and rely on it being really audible there and nothing else with a higher priority modfying it or getting into its way.
A flat root container with straight figures running from left to right may suggest you are dealing with a tape machine that uses some weird notation. But there is so much more in it that would be obfuscated and overly simplified if we used the term "track".
I love the looks of the new beta, and the ability to save vst/au presets and recall them quickly, without having to go trough all the category naming and such...It's quite a radical makeover...but I'm sure I'll get used to it soon enough, although I think there's still a lot of tabs/menus to go truogh, and still confused about the racks and stuff...
But I'm only talking after a few hours of testing, keep up the good work and simplifying things !
There is no track where you could place something and rely on it being really audible there and nothing else with a higher priority modfying it or getting into its way.
Andre, you have enough on your plate without having to engage in a philosophic discussion with me about concepts. But regardless, I think I want to clarify my view.
As I understand you, because of the hierarchical structure of containers' effects on instruments, you don't see this as a 'track.'
I still do, as there is only ever one voice streaming from where an instument is placed in a rack ... the original instrument ... regardless of how it is modified by other containers. In audio we might think of sends, prefader or postfader to aux buses. Containers are really no different than a conceptual or 'virtual' send of harmony. Or than using automation across a track or the harmonic equivalent of an articulation at some point across the timeline.
In the end, the timeline moves from left to right and the output arises from a single midi stream generating audio output from a sound source, i.e., always the same target. To me, using the same name for the target, i.e., the sound source, and the method of triggering it, i.e., the containers with instruments in an arrangement, is unintuitive. The linearity may not be structurally obvious, but it is implicit.
Anyway, that is why I think a track is still a legitimate conceptualization. Just because at some point in the linear flow the harmonic content is modified or muted by a container doesn't really change that.
It is late in the game and I wish I'd thought of this before. But I will introduce it for possible future consideration.
There would be one method to greatly decrease possible container 'hierarchical' confusion ... and conveniently for my make SFP/E more 'track' like.
Imagine that instead of there being entire hierarchical containers with the entire ensemble of instruments of the arrangement, there was simply hierarchical changes with each instrument in its own separate container. I could then look at any instrument and see the controlling phrase for that voice at any specific point in time. No confusion about what is playing where or what I need to modify.
This seems like it would preserve all the functionality, but make the instrument's harmonic variation more clearly like automation or articulation.
There may be some very good reasons why such a design would detract from other operations of SFP/ SFE ... and I'm sure someone will set me straight if there are ... but conceptually it seems more transparent and easier to work with the program if each instrument was in its own separate container with nesting within it. I see no reason why a change in the palette or progression couldn't as easily add a new element to each instrument container to then be muted or varied accordingly in the desired voicings at that point in the song.
Interesting discussion, but for a long time i am asking myself what is the strength of Synfire with his containers compared with for example Cubase/Logic ?
Shure, one can view the instruments on the arrange sheet as tracks, what at least their final midi output really is. I'm not saying this wasn't a valid perspective. My point is the term would overly simplify what the instruments are about.
Imagine that instead of there being entire hierarchical containers with the entire ensemble of instruments of the arrangement, there was simply hierarchical changes with each instrument in its own separate container.
This idea is not new to me. It has been considered very early already. The downside of isolating instruments this way is that you can not keep meaningful sections of the song together. In most cases, music is about multiple instruments playing together. Themes and textures arise from instruments interacting with each other. Containers are a great way to express this and move themes around as one unit in the composition.
Interesting discussion, but for a long time i am asking myself what is the strength of Synfire with his containers compared with for example Cubase/Logic ?
Logic has folders. MIDI regions are static, so their use for compositional purposes is very limited. I have used them for drums only.
As said, containers are a great way to keep a theme/texture together as one unit, move it around, try out progressions, etc. Containers are active components that can be used to compose algorithmically, too. Admittedly, this has not yet been shown in videos. I am eager to do this once 1.7 is out.
I don't know yet exactly what composing algorithmically holds, but in my composing with yamaha styles i used a particulair container by reposition against a another one and than listening what music comes up.
I even totally chance the order of the Yamaha songsections: used a "end" songsection container as "intro" container and the musical result counts only here..and did more with the containers... I was composing on this way.. see my soundcloud examples
One tab with Sound Racks with a page divived in two .."one arrangement" (Arrangement rack) and one for" multiple arrangement" (shared rack)
On the "one arrangement" part of the of the Sound Racks tab ..a symbolical drawing for the concept and the same for Multiple Arrangements
Sound[Rack, Device ,Device definition] ... keep it simple the fact that you are on the One arrangement part of the Sound Racks tab or Multiple Arrangements part is enough
No seperate naming for device or Device definition ..there is a One arrangment Rack and a Multiple arrangement Rack with a Sound device and a sound device definition ( description).
Fri, 2013-08-30 - 12:36 Permalink
@janamdo:
It is a bit difficult for me to follow your thoughts, but hopefully these tips will help you:
The new instrument inspector is used to SELECT a sound only: 1. Rack Module 2. Channel. If you want to CREATE a new module by loading a plug-in, for example, you must do that on the Rack tab now. The "Edit ..." item in the menu jumps you to the respective rack.
You need a shared GM device that is playable, if you want to import a GM midi file. Therefore I suggest you create a Halion shared device first. You can copy that into an arrangement later.
Fri, 2013-08-30 - 12:48 Permalink
A note to all interested testers:
You can participate simply by downloading version 1.7 from your user account, where it is listed now. Nothing else is required. Users not keen on being a lab rat should wait until the offcial 1.7 build is announced.
After installation, be sure you get the patches 1-4 in that exact order from the Help >> Online Updates menu. The patches will soon be obsolete after a new build was uploaded.
Fri, 2013-08-30 - 13:54 Permalink
Thanks
Well i studied the video where your started on the Instrument tab ..starting in the Rack tab seems to be more logical
Therefore i suggest earlier ( when you start on the instrument tab : Choose Rack there and show rack type ), but that is not the case as i understand.
So after first make a rack in the rack tab i can choose a sound in the instrument tab by choosing a Rackmodule and a channel?
Can you give a warning in the instrument tab : Define first your Rack in the Rack tab and choose here the sound for your Rack ?
Why don't you divide the Instrument tab in two sections ?: two knobs to go to the Rack tab
- arrangement Rack knob
- shared Rack knob
Both knobs got to the RAck page and as second section in the instrument tab : assign sound to Rack
As user you start in the arrangement Tab view ..SO YOU MUST FOCUS in this screen what RACK you want to use.
Its about userfriendlyness.. the user must be get be aware that two rack types are involved..and that all soundassigninging revolves around this..must be stressed out also in the manual.
The current instrument tab gives room for misuse .... don't give the user no chance to do that..you must lead them to the right path.
Do you get it ?
Make two prominent knobs on the instrument tab on the upperpart ( divive in two sections ) and the lower part label: choose sound for Rack
- Make arrangement Rack
- Make Shared Rack
Fri, 2013-08-30 - 15:33 Permalink
This is not handy too
Is it not possible when i assign GM DD in a arrangement rack that it will be used as a shared GM DD for HALion5 and than it can be used by the library?
So assigning a GM DD in arrangement Rack automatically assigns a shared GM DD to Halion5 for the library..like it was in the old Synfire Express ( can this be automated ? )
Another serious problem is that Synfire goes in a busy mode ( i don't have this with Cubase ) after a sort time.. doing another task for instance on my computer brings Synfire in a busy mode and it is freezing ...nothing to do with it anymore
Fri, 2013-08-30 - 17:34 Permalink
These two items appear in the popup menu, when the user attempts to select a device. If the desired device is not there, he goes to the "Edit ..." item. This item will receive a new name with the next update to make this more clear ("Edit Rack ..."). And I will put the shared rack on top of the menu, to make clear it is more common to use that rack first.
Only a shared device can be used by all open files and new imported files. If you create a private device, only that arrangement and its embedded library can use it. Private devices really only make sense if you use them ONLY in that arrangement. Or if you copy a shared device to the private rack (by selecting it from the menu) to MODIFY it for that one arrangement exclusively.
Fri, 2013-08-30 - 18:41 Permalink
It seems to be not possible the other way around ?..from a private DD go to a shared DD ?
I ask this because when i make a arrangement rack.. than the library will be working also too, as i am used to be in the old Synfire express, but there it was shared DD i think
But the idea to load first a DD(shared) and than load again a DD (arrangement )it is not attractive, because this is the only case that this happen..or not ?
Fri, 2013-08-30 - 19:17 Permalink
I thought this new soundassigning system was easier to use than the old one, but i am lost with the new soundassigning system for now....Synfire's GUI seems me not to help, but that is my impression.
Let other users give their experiences with the new soundassigning sytem, perhaps i must give it more attention and without less expectations ? or predominations.
Perhaps i am here too rigid and hold too much on my own ideas about this soundassigninging system.
Note: i don't know now anymore to make a "shared rack"(there is no Shared rack tab) for HALion5 ( not via the Instrument tab ..that was forbidden for the arrangement rack, but it is now allowed for the a shared rack ?..that is not consistent )
Fri, 2013-08-30 - 20:54 Permalink
From the popup menu on the instrument inspector, select "Edit Rack ...", or click the button with the toolbox icon. That will jump you to the shared rack. There you can create shared devices.
As always, changes take some time to get used to.
Fri, 2013-08-30 - 20:55 Permalink
Note to all testers: A new build is online for download now. This is not a patch, that is, you need to visit your user accounts and get the download from there.
Thanks a lot for your feedback so far!
Fri, 2013-08-30 - 22:16 Permalink
I do have a another solution for this ..to be consistent ..see other post : divide the rack tab and add two drawings for the concept ..see..
no, it seems to me a wrong direction and not intuiative and logical ..that's why i am getting lost in this soundsetup
Fri, 2013-08-30 - 22:24 Permalink
seems Library resize issue fixed in latest 1.7b4.
@ Andre
i guess you will be very bussy in this beta test / fix period
but i have to ask ,
- should i expect any fix or workaround solution to (my specific) DD problem to continue to use SFP as before?
- anytime soon ?
i am asking this because if not ,
seems to me is better to switch back to 1.6.6.
to bring back to life my workflow + projects for now .
so shortly i can continue to work.
Best Regards
Yıldırım
Fri, 2013-08-30 - 22:57 Permalink
@ Bagatell
if this was to me thank you and sorry i miss that before..
if it wasn't to me ...
well , just ignore this post.
Best whishes
Sat, 2013-08-31 - 00:21 Permalink
I've had a couple of crashes tonight. Can't remeber what I was doing the first time, but second time I had just added a new private plugin (Halion 5) to a new arrangement. I clicked the DD and it crashed. Crash reports submitted.
Ah well, time for bed anyway!
zzzzzzzzzzzzzzzz
Sat, 2013-08-31 - 11:08 Permalink
@soundcase:
Let's discuss your workflow via email directly. I'll contact you. If I find a solution, I will post it here. But first I will need to fully understand what you are doing. I am confident it will work, because the new design can basically do almost anything. Your 300 DDs are not lost, that's for sure.
Sat, 2013-08-31 - 18:47 Permalink
Thanks and yes its better .
Sun, 2013-09-01 - 10:39 Permalink
There's currently a very important discussion going on here:
(https://users.cognitone.com/content/why-there-no-shared-rack-tab)
It's about naming and placement of items in the user interface. I wanted to note this here, so anyone who's interetsted can contribute to that discussion. Before it's too late.
Sun, 2013-09-01 - 19:44 Permalink
May I suggest you list the current item names under discussion for renaming, to ensure that all of the interacting items, e.g., 'shared rack,' 'private rack,' etc., are renamed as an integrated system where appropriate, as opposed to as individual items?
What primarily has been discussed in this linked thread is racks and global instruments ... but there may be some other things that could be considered.
For example, I have always considered the use of the term 'instruments' in the arrangment window confusing. To me they are 'tracks' to which various instruments can be assigned. Calling them tracks would not prevent them from being automatically renamed when an instrument sound was selected. This is not a big deal once you understand the system, but is confusing at the beginning.
This is just an example to point out that it would be helpful in considering these things to have your list of what is under consideration.
Best regards!
Sun, 2013-09-01 - 22:35 Permalink
I'll put together some suggestions for the terminology so we can discuss them.
As for "tracks" vs. "instruments", there is no such thing like a track in Synfire. Tracks are linear space on a tape where you can record anything anywhere on the timeline.
The container structure of Synfire is a tree with phrases of different lengths, loop sizes, hanging at its branches, so to speak, overlapping each other, overriding each other. And all this per each parameter individually.
There is no track where you could place something and rely on it being really audible there and nothing else with a higher priority modfying it or getting into its way.
A flat root container with straight figures running from left to right may suggest you are dealing with a tape machine that uses some weird notation. But there is so much more in it that would be obfuscated and overly simplified if we used the term "track".
I will let the terms breed in my head tonight.
Mon, 2013-09-02 - 01:49 Permalink
Would "channel" be more appropiate ?
I love the looks of the new beta, and the ability to save vst/au presets and recall them quickly, without having to go trough all the category naming and such...It's quite a radical makeover...but I'm sure I'll get used to it soon enough, although I think there's still a lot of tabs/menus to go truogh, and still confused about the racks and stuff...
But I'm only talking after a few hours of testing, keep up the good work and simplifying things !
Mon, 2013-09-02 - 02:53 Permalink
Andre, you have enough on your plate without having to engage in a philosophic discussion with me about concepts. But regardless, I think I want to clarify my view.
As I understand you, because of the hierarchical structure of containers' effects on instruments, you don't see this as a 'track.'
I still do, as there is only ever one voice streaming from where an instument is placed in a rack ... the original instrument ... regardless of how it is modified by other containers. In audio we might think of sends, prefader or postfader to aux buses. Containers are really no different than a conceptual or 'virtual' send of harmony. Or than using automation across a track or the harmonic equivalent of an articulation at some point across the timeline.
In the end, the timeline moves from left to right and the output arises from a single midi stream generating audio output from a sound source, i.e., always the same target. To me, using the same name for the target, i.e., the sound source, and the method of triggering it, i.e., the containers with instruments in an arrangement, is unintuitive. The linearity may not be structurally obvious, but it is implicit.
Anyway, that is why I think a track is still a legitimate conceptualization. Just because at some point in the linear flow the harmonic content is modified or muted by a container doesn't really change that.
Mon, 2013-09-02 - 03:09 Permalink
It is late in the game and I wish I'd thought of this before. But I will introduce it for possible future consideration.
There would be one method to greatly decrease possible container 'hierarchical' confusion ... and conveniently for my make SFP/E more 'track' like.
Imagine that instead of there being entire hierarchical containers with the entire ensemble of instruments of the arrangement, there was simply hierarchical changes with each instrument in its own separate container. I could then look at any instrument and see the controlling phrase for that voice at any specific point in time. No confusion about what is playing where or what I need to modify.
This seems like it would preserve all the functionality, but make the instrument's harmonic variation more clearly like automation or articulation.
There may be some very good reasons why such a design would detract from other operations of SFP/ SFE ... and I'm sure someone will set me straight if there are ... but conceptually it seems more transparent and easier to work with the program if each instrument was in its own separate container with nesting within it. I see no reason why a change in the palette or progression couldn't as easily add a new element to each instrument container to then be muted or varied accordingly in the desired voicings at that point in the song.
Mon, 2013-09-02 - 05:08 Permalink
Interesting discussion, but for a long time i am asking myself what is the strength of Synfire with his containers compared with for example Cubase/Logic ?
Mon, 2013-09-02 - 09:47 Permalink
Shure, one can view the instruments on the arrange sheet as tracks, what at least their final midi output really is. I'm not saying this wasn't a valid perspective. My point is the term would overly simplify what the instruments are about.
This idea is not new to me. It has been considered very early already. The downside of isolating instruments this way is that you can not keep meaningful sections of the song together. In most cases, music is about multiple instruments playing together. Themes and textures arise from instruments interacting with each other. Containers are a great way to express this and move themes around as one unit in the composition.
Logic has folders. MIDI regions are static, so their use for compositional purposes is very limited. I have used them for drums only.
As said, containers are a great way to keep a theme/texture together as one unit, move it around, try out progressions, etc. Containers are active components that can be used to compose algorithmically, too. Admittedly, this has not yet been shown in videos. I am eager to do this once 1.7 is out.
Mon, 2013-09-02 - 10:36 Permalink
I don't know yet exactly what composing algorithmically holds, but in my composing with yamaha styles i used a particulair container by reposition against a another one and than listening what music comes up.
I even totally chance the order of the Yamaha songsections: used a "end" songsection container as "intro" container and the musical result counts only here..and did more with the containers...
I was composing on this way.. see my soundcloud examples
Mon, 2013-09-02 - 13:19 Permalink
Here's an overview of what the shared (global) and private stuff is about. The black arrows denote the direction of usage, i.e. what uses what.
Tue, 2013-09-03 - 11:57 Permalink
After thinking a lot about it, this naming is what I came up with:
Global Sounds:
Global Devices
Global Rack
Global Instruments
Arrangement Sounds:
Arrangement Devices
Arrangement Rack
Depending on the file type, "Arrangement Rack" would be called "Song Rack", or "Sketch Rack".
In the documentation and everywhere where is more room for text, I will use "Device Definitions" as the long form of "Devices".
It is inevitable that at some places a generic term is needed for what is "private" now. I don't believe "Local" would cut it, or what do you think?
If anyone has concerns, let me know now. Otherwise this will get changed for the next build.
EDIT: I'll stay with "Description". Changing this would mean too much hassle for too little gain.
Tue, 2013-09-03 - 12:13 Permalink
Andre,
I havent been following all the discussion as it was going to be very technical and outside my kwnolegde of synfire
just one question to sum everything up:
arrangement track is for arrangement (I create vst, instruemnt that are NOT visible outside the project)
global is for shared?(I create vst, instruemnt that are visible outside the project)
sorry but I justy could not follow everything
thanks
Tue, 2013-09-03 - 12:15 Permalink
Yes, Arrangement Rack is for inside one file only.
Global Rack is for all (multiple) files, sketches, palettes, in common.
Tue, 2013-09-03 - 12:46 Permalink
sorry to bother you, but if the arrangemnt tracks are not visible outside the project why it requires so many steps to drop a vst inside the project?
new comers, to test synfire will want just to drop a vst and try ideas out..this is the most simple setup that one expect coming from the DAW world
I know that for globa I do it once but what about arrangment?
Tue, 2013-09-03 - 13:24 Permalink
Single Arrangement --> Sound Racks--> Sound device --> Sound device definition
Multiple arrangements--> Sound Racks --> sound device --> Sound device defintion
One tab with Sound Racks with a page divived in two .."one arrangement" (Arrangement rack) and one for" multiple arrangement" (shared rack)
On the "one arrangement" part of the of the Sound Racks tab ..a symbolical drawing for the concept and the same for Multiple Arrangements
Sound[Rack, Device ,Device definition] ... keep it simple the fact that you are on the One arrangement part of the Sound Racks tab or Multiple Arrangements part is enough
No seperate naming for device or Device definition ..there is a One arrangment Rack and a Multiple arrangement Rack
with a Sound device and a sound device definition ( description).
Crazy all those names..