After thinking a lot about it, this naming is what I came up with:
Global Sounds: Global Devices Global Rack Global Instruments
The term "Global Instruments" would mean the same as before (i.e. they are the Instruments "Chords", "Bass", "Guitar",...), right?
This could cause confusion (as you have already noted yourself), because then the term "global" is used ambiguously. One could think that the Global Sounds can only be used with these Global Instruments or the Global Rack is only there to define sounds for the Global Instruments. Looking for a new name for the "Global Instruments" would probably be useful.
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?
Because a VST is a black box that does not tell what's inside. Even if you point Synfire to a MIDI channel, it would still not know what's behind the channel. DAWs do not need to know, because they just pump out static data to the channel (and don't care whether that works, or not).
One could think that the Global Sounds can only be used with these Global Instruments or the Global Rack is only there to define sounds for the Global Instruments.
I'm no longer that sceptical regarding this. Global is a term broad enough to suggest "usable everywhere", which is exactly what all these entities are. Global instruments can in fact only use the global rack for looking up sounds, as the similar names suggest.
ok I give up, just dont understand sorry ...what I'm saying is this, when I insert 3 vst inside synfire I have to follow the same exact steps for all of them..thats makes me think that could me automated
also, usually I use synfire with loopback..synfire does not know what there is behind the channel so thats why its difficult for me to understand
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.
This 'downside' can and has been addressed in other ways. I understand and value the need to be able to relocate sections. Cubase does this in a very clever way with the Arranger, which preserves the linearity of the 'tracks' idea, but permits auditioning multiple ways and arranging and repeating selected sections across the time line and then 'flattening' the composition out once the desired arrangement is reached. The goal is the end result, not the method.
As ignorant as I am of coding, I have little clue as to what is possible ... except for the results I see in various software programs
Perhaps the 'Holy Grail' would be a combination of what SFP does with containers and what Cubase does where it is able to 'remember' and name the selected section as a moveable piece in a 'track container.'
This would be that the container retains it's identity and can be moved anywhere in the arrangemetn time line, but that there is a view toggle showing either the containers as currently or each section of the container collapsed into it's instrument. The successive containers could add a subscript like "_a, _b, _c, " etc. to the phrase names to show their hierarchal dominance, perhaps in regular color with the superceded phrases in subdued colors.
As I said, I do not understand what is possible in coding. But such a scheme would vastly increase the user friendliness and intuitiveness of SFP/E.
This could cause confusion (as you have already noted yourself), because then the term "global" is used ambiguously. One could think that the Global Sounds can only be used with these Global Instruments or the Global Rack is only there to define sounds for the Global Instruments. Looking for a new name for the "Global Instruments" would probably be useful.
Jürgen, I agree. I would propose simply using the term Audition Rack or System Rack, which contains those Global Instrument Devices ... but could be changed out for any other 'global' instrument if the user so desired. This would identify them as used for SFP/E audtioning as a function, but that otherwise they are just the same instrument devices that can be utilized in any Global Rack.
I still think we continue the confusing difficulty that what more generally in music software would be considered an instrument, i.e., in SFP/E speak a 'device,' here has a different meaning.
Perhaps what SFP/E calls instrument should instead be called a Player or Performer ... as this is more descriptive of how 'Instruments' now function. Then 'Instrument' could be used for Devices, reducing ambiguity and increasing user friendliness.
Global instruments can in fact only use the global rack for looking up sounds, as the similar names suggest.
Ok, but the main purpose of the Global Instruments is not to be "global", is it? They are mainly used to produce some standard sounds, for example the standard chords sound at the palettes if no sketch is loaded. Therefore something like 'Standard/Basic/Audition/System Instruments' maybe could express more specific what these instruments are usually used for.
Anyway, it's true that the Global Instruments can use only sounds of the Global Rack, but I hope that nobody thinks that the same is true vice versa, i.e. that the Global Rack is just there to provide sounds for these five or six (not sure how many they are, I'm not at the computer right now) 'Global Instruments'.
Coding can do anything. The question is how would that work with all the user's different workflows and expectations. And how would that support the genuine prototyping workflows users are not yet familiar with.
There is plenty room for improving the container overview in many ways. Just to name a few, two of the ideas breeding in my head are:
Provide an alternative "flat" view on the whole arrangement, using containers to select and edit portions of it. That's pretty linear and easy to overview, but with very intelligent editing.
Check individual instruments to be included with a container or not. The container defaults (common parameters) would then only affect the selected instruments. One could, for example, change the rhythm of all violins by dropping a single Step vector.
Before doing more sophisticated things however, we need to make sure everyone is getting along with the basics well. Then we will introduce the genuine prototyping workflows. After these will have settled a bit, user feedback will be pointing out different directions, not anymore so much influenced by DAW habits. That's when Synfire will be approaching its genuine destination.
@juergen:
Ok, but the main purpose of the Global Instruments is not to be "global", is it?
Sure, it absolutely is. Arrangements, sketches or whatever can select the global instruments as a placeholder for their own instruments. In whatever studio a file will be opened, it will resolve to the global instruments the respective user has set up there. This in indispensible for making sketches portable, for example.
As for the names and terms, this is impossible to make perfect. I will upload a new build tomorrow with the suggested terms already changed (and some 50 or so bugs fixed). Let's play a few days with it and see if it feels ok.
I still think we continue the confusing difficulty that what more generally in music software would be considered an instrument, i.e., in SFP/E speak a 'device,' here has a different meaning.
The natural meaning of "instrument" actually is a physical thing a player holds in his hands. More or less. The modern notion referring to plug-ins, audio files or synthesizers is already a considerable abstraction :D
You are right that Synfire's notion of Instrument is closer to Player than to Sampler.
The natural meaning of "instrument" actually is a physical thing a player holds in his hands. More or less. The modern notion referring to plug-ins, audio files or synthesizers is already a considerable abstraction
You are right that Synfire's notion of Instrument is closer to Player than to Sampler.
To the American ear, 'Performer' sounds much more elegant than 'Player,' which is too easily confused with 'Playa!'
Andre, you have the 'high ground' with both the overview of current development and the vision for the future. I will always defer to your judgment (not that I have any choice! :) ),
But I so appreciate your willingness to engage in these discussions and I am glad my own 'conceptualizations' do make sense to you.
Sure, it absolutely is. Arrangements, sketches or whatever can select the global instruments as a placeholder
for their own instruments. In whatever studio a file will be opened, it will resolve to the global instruments the respective user has set up there. This in indispensible for making sketches portable, for example.
Ok, I see your point. But maybe that's more the developers point of view ;)
1. Provide an alternative "flat" view on the whole arrangement, using containers to select and edit portions of it. That's pretty linear and easy to overview, but with very intelligent editing.
2. Check individual instruments to be included with a container or not. The container defaults (common parameters) would then only affect the selected instruments. One could, for example, change the rhythm of all violins by dropping a single Step vector.
Very good ideas. I'm looking forward to that. The new Matrix view is already a big step forward, btw. Very helpful to get a better overview of the parameter settings.
Only there is Global Sounds and Global rack and Global Instruments..tabs A new user can find this confusing..or not ?
Perhaps a short explanation on the Global Instruments Tab page where the Global instruments are used for ..or a symbolic pic ...like there is also a explanation for a Global Rack ( also here is room for a symbolic pic for the concept )
Also a symbolic pic for the arrangement rack
I am pleased with this version of Synfire..
Note
Well it seems that browser chrome makes no freezes with Synfire anymore ..all problems solved
Arrangement rack : Rack modules and devices descriptions you crate here are available to this (arrangement) file only
Note: name this file
Cannot understand why i call this earlier primitive a soundtab,because this is the solution, it very userfriendly now and it revolves about assigning sounds
Internal Instruments, hmm. Since the internal rack is hidden, unless the user really wants to unhide it, this would probably also be confusing. At least it is logical. I'll chew on it.
Just found a very serious bug with selecting a device from the popup menu: Switching from one device to an other disconnected all other rack modules. That's a true nuke.
Patch #6 is online to fix this. Everyone should immediately get it, or device selections on your racks are doomed. Also be sure you have build #18 (Mac) or #4 (Windows) installed.
A bug with the Tempo parameter (tested on SF Express 1.7b4 Win): The Tempo parameter can only be changed at the root container. If I select another container and try to change Tempo there, it is nevertheless changed at the root container.
By the way: There is still much room at the bottom of the window (next to the transport buttons). Wouldn't it be a good idea to show the tempo there? It's a bit annoying that you always have to select the Tempo parameter and the container in which it is set, to see the current tempo.
I am happy to share my panic attack= DD issue now solved ! :yeah:
also i want to thank you again Andre for this fast response and special support!
i know this specific to my workflow only but anyway just for the rcords here is the procedure from Andre's email:
just in case backup your DAW Track Templates first and then
0.Before the load any Track Templates in DAW , Run Synfire First !
1. Load DAW template 2. In global rack, select DAW host, press +, pick the reserved drone(s) 3.select "Match Device Description" from the module's menu check if DD correct ( i had no problem in this step so every DD matched perfectly) then 4. re- Save DAW Track Template 5. delete Track from DAW and delete that module from Synfire ( press "x" ) ! and don't worry about the Synfire's warning message, just press to YES.. thats it!
Thanks. The solution was however not exclusively taylored to your workflow. It is a valid question to ask what happens to drones that appear out of nowhere on the LAN, because the user started a DAW with global drones in it, or restarted a crashed Engine.
With the help of transient rack modules (gray), these orphaned drones are no longer invisible. Now that they appear on the global rack, the user has the option to grab or discard them.
I am having problems too. The 'retain midi channel' does not work, channels get shuffled around.. When I first import the file. It sounds the same as in Logic, but after I import it as all static channels most things are wrong, and sound assignments assignments change,, and sometimes two midi tracks end up having the same patch.. In general, this is worse than before in this regard..
When there is a device list, be it GM or Roland or Yamaha, SFP should look up in its table, It appears to be only paying attentions to the program and not the MSB/LSB.. So a certain Tyros bass always comes up as an organ, and other instruments are off too. Most manufactores would use the same program # for a particular sound, and use the MSB/LSB to select various banks...Yamaha did not follow this convention. hence SFP is getting programs wrong.. SFP needs to look up the MSB/LSB combination, or just pass it on, and not modify it into the wrong catagory. Since SFP has a Tyros device list it should refer to it when determining sounds.. This is still a 'sore' spot.. Are we going to get device lists for all the instruments that are out there. I think not; this will alway be a rough spot, unless Andre comes up with a Device creator program, (which would be truly great)... I know my hardwares and libraries, I know where to go to get the sound I need. I would think other studio operatiors would too
How is one going to deal with these new super sound libraries, that have arpeggios, slurs, slides, etc.. I guess that would be a stage SFP leaves for the DAW.. But the fact is, when you're creating a piece you need to have 'what you see is what you get'.. I need to have the finished sound, with articulated, burps, chirps, squeaks, slides, arpeggios.. Otherwise I can't build on what is not audibly there.. That's why I go back/forth between Logic/SFP. A real rich string patch is going to inspire you to play and create totally different than a bland string sound..
It would also be nice if SFP had a MIDI event list so you could track down problems.. When an instrument is bare, (no containers or processes working) that the midi list would display that.. When you add a modifying container, or process, the event list should reflect that. We need mute containers, and mute notes, to further isolate snafu's..
There has been a lot of discussion about SFP not having tracks.. But the truth is it is a track, it is just being modified by different parameters.. When you set up instruments in your DAW be they hardware or Virtual, you are going to set up certain effects and you always want it to go to the same track or channel strip. Otherwise, effects, eq, instruments are going to be jumping all over your instrument or DAW Mixer window. Making it impossible to mix..
SFP with it's dynamic allocation, throws all your DAW setup/effects out the window.. When you set up a song one always wants a certain instrument on a certain midi channel going to a certain device and to the same track in the DAW, otherwise you are constantly resuffleing.. This can be rectified by reserving channels, than what's the point of dynamic patches/channels in the first place?
The Import window should have the MIDI CHANNEL #,, that is far more relevent than what SFP Track# wants to assign.. it should show an event list, so you can double check what you are doing. For instance I always want my track configurations to follow Yamaha's protocal.. MIDI channel 11 is always bass..That way when there is a problem one can quickly track down the culprit. The arrange parameters should directly allow you to change MIDI channel, catagory, MSB/LSB, Program right from that window, not jumping around.. Others of use will follow BIAB, or Roland etc.. In fact I don't know of any studio, that doesn't keep a set order of instruments so they can quickly effect changes.
I want the track list in SPF to look exactly as the track list in Logic, so I know what's going on.
(OK ...I've calmed down now... I didn't mean for this to sound like a rant.... please don't take it that way, but I feel very passionate about the subjects, I brought up, Without this, SFP is becoming more abstract.. I want to master it like Logic and know that if I do A, B C and D - I will end up with E... I'm finding it hard, to grasp all the processes and feel secure I can arrive at the result I am looking for with SFP. And until SFP reaches that plateau, it will remain in the esoteric catogory. I love the esoteric about it, cause it can do no other software, but I want to feel more competent with it. I can use BIAB's 'generate song command' to create all the 'happy accidents' i want..
Admittedly this is my first stab at the beta, so perhaps I am missing a lot of points,, but it doesn't readily appear to be simpler, just different. This whole situation of global, shared, private, midi racks,, should just be boiled down to one thing.. Pick a sound source (virtual instrument, MIDI hardware), pick a MIDI Channel # pick a catagory, (So SPF knows the boundaries), pick MSB/LSB/Prog. Save that as a song or template so you can use the same setup again..
I have a set of control sequences already built into my Logic template.. So I can quickly grap, a piano, acoustic guitar, epiano, etc.. As the song develops, then I go in and perhaps pick a different song, and put the appropriate MSB/LSB/Prog.
This is one of the most frustrating aspects of MIDI hardware modules, is getting them to sound exactly the same each time you pull up a multi - channel patch to play .. I often struggle with Motif rack to get same sounds. Tyros is work too, Tyros has a limited number of effects as many hardware modules do, so the 9 effects DSP's have to be spread over the 16 midi channels.. If a new patch is called up and needs a DSP, it robs from another location, so that instrument looses some of it's original programmed sound..
If you really want to get into the nuts and bolts of it, you're gonna have to learn sysex, and send sysex commands to your boxes to totally and completely program them ... Sorry sysex - is where I draw the line.. And I don't think Andre wants to deal with that, and I know that I don't either.. Still it is one of the obstacles..
Also when importing MIDI files static into SFP, theres needs to be a 'leave articulations intact' button.. That is notes in extreme high or low octaves, should be left alone and not processed If you copy of paste a section the 'articulation notes' get copy/pasted too..
As it is now, when you import a MIDI trackstatic , the first thing SFP tells you it is transposing out of range notes, thus destroying all your articulations you worked so hard to put into your original MIDI sequence.
As it is now,, I strip off the high articulation notes, import into SFP, export back to Logic, then re-add articulations, sometimes having to create more to deal with the changes SFP made.
Hmm. Most, if not all issues boil down to these three points:
Midi import is broken, 'retain midi channel' and sound lookup do not work.
You want to see midi channels on import window
Articulations should be filtered out
No need to argue, I will look into this. I already suspected the import to misbehave.
Except for 3, which is impossible, unfortunately. For most libraries I've seen, articulations are just 1 octave below the playing range, some even closer. Some even an octave above. That's impossible for Synfire to tell apart from music. Unless it already knows the exact pitch range of the particular sound.
I will check if a combination of "Don't Transpose" on import and "Strip Take Outside Range" after import would make sense. Or some single switch somewhere.
Tue, 2013-09-03 - 13:41 Permalink
The term "Global Instruments" would mean the same as before (i.e. they are the Instruments "Chords", "Bass", "Guitar",...), right?
This could cause confusion (as you have already noted yourself), because then the term "global" is used ambiguously. One could think that the Global Sounds can only be used with these Global Instruments or the Global Rack is only there to define sounds for the Global Instruments. Looking for a new name for the "Global Instruments" would probably be useful.
Tue, 2013-09-03 - 13:51 Permalink
[Catalog(chords)-Pallete-Sketch ]-Instruments..(give the animal a name (dutch proverb ;) )
Tue, 2013-09-03 - 14:10 Permalink
Because a VST is a black box that does not tell what's inside. Even if you point Synfire to a MIDI channel, it would still not know what's behind the channel. DAWs do not need to know, because they just pump out static data to the channel (and don't care whether that works, or not).
I'm no longer that sceptical regarding this. Global is a term broad enough to suggest "usable everywhere", which is exactly what all these entities are. Global instruments can in fact only use the global rack for looking up sounds, as the similar names suggest.
Tue, 2013-09-03 - 15:14 Permalink
ok I give up, just dont understand sorry ...what I'm saying is this, when I insert 3 vst inside synfire I have to follow the same exact steps for all of them..thats makes me think that could me automated
also, usually I use synfire with loopback..synfire does not know what there is behind the channel so thats why its difficult for me to understand
but anyway I will still use synfire this way
Tue, 2013-09-03 - 17:33 Permalink
Yes, you can greatly speed this up with presets. I will show that in a video soon.
Tue, 2013-09-03 - 18:50 Permalink
This is looking pretty good ... if I understand. Shared = Global and Private = Arrangement, correct?
Perhaps what was previously called Global Rack could be System Rack or, perhaps better, Audition Rack?
Otherwise, I don't see how this scheme makes that differentiation.
Tue, 2013-09-03 - 19:09 Permalink
This 'downside' can and has been addressed in other ways. I understand and value the need to be able to relocate sections. Cubase does this in a very clever way with the Arranger, which preserves the linearity of the 'tracks' idea, but permits auditioning multiple ways and arranging and repeating selected sections across the time line and then 'flattening' the composition out once the desired arrangement is reached. The goal is the end result, not the method.
As ignorant as I am of coding, I have little clue as to what is possible ... except for the results I see in various software programs
Perhaps the 'Holy Grail' would be a combination of what SFP does with containers and what Cubase does where it is able to 'remember' and name the selected section as a moveable piece in a 'track container.'
This would be that the container retains it's identity and can be moved anywhere in the arrangemetn time line, but that there is a view toggle showing either the containers as currently or each section of the container collapsed into it's instrument. The successive containers could add a subscript like "_a, _b, _c, " etc. to the phrase names to show their hierarchal dominance, perhaps in regular color with the superceded phrases in subdued colors.
As I said, I do not understand what is possible in coding. But such a scheme would vastly increase the user friendliness and intuitiveness of SFP/E.
Well, I can dream, can I not?
Tue, 2013-09-03 - 19:31 Permalink
Jürgen, I agree. I would propose simply using the term Audition Rack or System Rack, which contains those Global Instrument Devices ... but could be changed out for any other 'global' instrument if the user so desired. This would identify them as used for SFP/E audtioning as a function, but that otherwise they are just the same instrument devices that can be utilized in any Global Rack.
I still think we continue the confusing difficulty that what more generally in music software would be considered an instrument, i.e., in SFP/E speak a 'device,' here has a different meaning.
Perhaps what SFP/E calls instrument should instead be called a Player or Performer ... as this is more descriptive of how 'Instruments' now function. Then 'Instrument' could be used for Devices, reducing ambiguity and increasing user friendliness.
Tue, 2013-09-03 - 21:06 Permalink
Ok, but the main purpose of the Global Instruments is not to be "global", is it? They are mainly used to produce some standard sounds, for example the standard chords sound at the palettes if no sketch is loaded. Therefore something like 'Standard/Basic/Audition/System Instruments' maybe could express more specific what these instruments are usually used for.
Anyway, it's true that the Global Instruments can use only sounds of the Global Rack, but I hope that nobody thinks that the same is true vice versa, i.e. that the Global Rack is just there to provide sounds for these five or six (not sure how many they are, I'm not at the computer right now) 'Global Instruments'.
Tue, 2013-09-03 - 22:37 Permalink
@Prado:
Coding can do anything. The question is how would that work with all the user's different workflows and expectations. And how would that support the genuine prototyping workflows users are not yet familiar with.
There is plenty room for improving the container overview in many ways. Just to name a few, two of the ideas breeding in my head are:
Before doing more sophisticated things however, we need to make sure everyone is getting along with the basics well. Then we will introduce the genuine prototyping workflows. After these will have settled a bit, user feedback will be pointing out different directions, not anymore so much influenced by DAW habits. That's when Synfire will be approaching its genuine destination.
@juergen:
Sure, it absolutely is. Arrangements, sketches or whatever can select the global instruments as a placeholder for their own instruments. In whatever studio a file will be opened, it will resolve to the global instruments the respective user has set up there. This in indispensible for making sketches portable, for example.
As for the names and terms, this is impossible to make perfect. I will upload a new build tomorrow with the suggested terms already changed (and some 50 or so bugs fixed). Let's play a few days with it and see if it feels ok.
Tue, 2013-09-03 - 22:51 Permalink
The natural meaning of "instrument" actually is a physical thing a player holds in his hands. More or less. The modern notion referring to plug-ins, audio files or synthesizers is already a considerable abstraction :D
You are right that Synfire's notion of Instrument is closer to Player than to Sampler.
Tue, 2013-09-03 - 23:13 Permalink
To the American ear, 'Performer' sounds much more elegant than 'Player,' which is too easily confused with 'Playa!'
Andre, you have the 'high ground' with both the overview of current development and the vision for the future. I will always defer to your judgment (not that I have any choice! :) ),
But I so appreciate your willingness to engage in these discussions and I am glad my own 'conceptualizations' do make sense to you.
Tue, 2013-09-03 - 23:55 Permalink
Ok, I see your point. But maybe that's more the developers point of view ;)
Very good ideas. I'm looking forward to that. The new Matrix view is already a big step forward, btw. Very helpful to get a better overview of the parameter settings.
Wed, 2013-09-04 - 14:49 Permalink
New builds are online. Enjoy!
Wed, 2013-09-04 - 16:26 Permalink
Yes thanks very much ..i am curious
==================================================
Sounds tab--> clear ! ..a new user knows where he must now go for the sounds
===================================================
Only there is Global Sounds and Global rack and Global Instruments..tabs
A new user can find this confusing..or not ?
Perhaps a short explanation on the Global Instruments Tab page where the Global instruments are used for ..or a symbolic pic ...like there is also a explanation for a Global Rack ( also here is room for a symbolic pic for the concept )
Also a symbolic pic for the arrangement rack
I am pleased with this version of Synfire..
Note
Well it seems that browser chrome makes no freezes with Synfire anymore ..all problems solved
---------------------------------------------------------
Arrangement rack : Rack modules and devices descriptions you crate here are available to this (arrangement) file only
Note: name this file
Cannot understand why i call this earlier primitive a soundtab,because this is the solution, it very userfriendly now and it revolves about assigning sounds
Thu, 2013-09-05 - 20:39 Permalink
Just one more suggestion for the Global Instruments (then I'II say nothing more about that):
Internal Sounds:
Internal Rack
Internal Device Descriptions
⇩
Internal Instruments
Isn't that logical?
Thu, 2013-09-05 - 20:55 Permalink
Internal Instruments, hmm. Since the internal rack is hidden, unless the user really wants to unhide it, this would probably also be confusing. At least it is logical. I'll chew on it.
NEW BUILDS ONLINE AGAIN ! :yeah:
Fri, 2013-09-06 - 04:03 Permalink
The .exe file for the new build gave me an error, so I installed using the .msi files, which worked fine.
This latest build is a VERY noticeable improvement.
Even though I didn't know exactly what I was doing, I was impressed with how much easier it is to figure things out.
I'm sure it will only get better.
Fri, 2013-09-06 - 09:36 Permalink
Hi
Thanks to your new update
1*-Please see my pictures,the container error it follows in this update
2*-What means the point blank is above the bass symbol in the toolbar?
Regards
Fri, 2013-09-06 - 10:16 Permalink
Hi
Please more video tutorials
I can,t live without them
* Synfire All Users say : +1
Fri, 2013-09-06 - 14:18 Permalink
That point is a handle for moving the split line between container view and the rest (resizer). Maybe I should remove it.
Fri, 2013-09-06 - 21:53 Permalink
Just found a very serious bug with selecting a device from the popup menu: Switching from one device to an other disconnected all other rack modules. That's a true nuke.
Patch #6 is online to fix this. Everyone should immediately get it, or device selections on your racks are doomed. Also be sure you have build #18 (Mac) or #4 (Windows) installed.
See Help >> Online Updates.
:oops:
Sat, 2013-09-07 - 07:43 Permalink
+1 on video tutorials!
Sun, 2013-09-08 - 00:17 Permalink
A bug with the Tempo parameter (tested on SF Express 1.7b4 Win): The Tempo parameter can only be changed at the root container. If I select another container and try to change Tempo there, it is nevertheless changed at the root container.
By the way: There is still much room at the bottom of the window (next to the transport buttons). Wouldn't it be a good idea to show the tempo there? It's a bit annoying that you always have to select the Tempo parameter and the container in which it is set, to see the current tempo.
Tue, 2013-09-10 - 12:38 Permalink
Hello Andre,
just wanted to give you brief description of my tests with synfire pro 1.7 #18
I am mostly using it with the integrated GM lib for exporting to .mid and using result in my Ableton DAW.
Sometimes instruments are muted for 1 beat in the first container when starting playing.
When I reimport a .mid exported with synfire the Drum-Track isn't recognized as Drums but as "New Sound"
Gonna test more this week.
Oooh and Synfire looks great now!
Greetings from Hamburg
Tue, 2013-09-10 - 18:43 Permalink
I am happy to share
my panic attack= DD issue now solved ! :yeah:
also i want to thank you again Andre for this
fast response and special support!
i know this specific to my workflow only
but anyway
just for the rcords
here is the procedure from Andre's email:
just in case backup your DAW Track Templates first and then
0.Before the load any Track Templates in DAW , Run Synfire First !
1. Load DAW template
2. In global rack, select DAW host, press +, pick the reserved drone(s)
3.select "Match Device Description" from the module's menu
check if DD correct ( i had no problem in this step so every DD matched perfectly) then
4. re- Save DAW Track Template
5. delete Track from DAW and delete that module from Synfire ( press "x" ) !
and don't worry about the Synfire's warning message, just press to YES..
thats it!
Wed, 2013-09-11 - 09:31 Permalink
@soundcase:
Thanks. The solution was however not exclusively taylored to your workflow. It is a valid question to ask what happens to drones that appear out of nowhere on the LAN, because the user started a DAW with global drones in it, or restarted a crashed Engine.
With the help of transient rack modules (gray), these orphaned drones are no longer invisible. Now that they appear on the global rack, the user has the option to grab or discard them.
Wed, 2013-09-11 - 23:13 Permalink
I am wondering, does the midi import work right for all other users? Coz on my Win7 nearly every midi-file I tried has wrong instruments ...
Thu, 2013-09-12 - 06:35 Permalink
I am having problems too. The 'retain midi channel' does not work, channels get shuffled around.. When I first import the file. It sounds the same as in Logic, but after I import it as all static channels most things are wrong, and sound assignments assignments change,, and sometimes two midi tracks end up having the same patch.. In general, this is worse than before in this regard..
When there is a device list, be it GM or Roland or Yamaha, SFP should look up in its table, It appears to be only paying attentions to the program and not the MSB/LSB.. So a certain Tyros bass always comes up as an organ, and other instruments are off too. Most manufactores would use the same program # for a particular sound, and use the MSB/LSB to select various banks...Yamaha did not follow this convention. hence SFP is getting programs wrong.. SFP needs to look up the MSB/LSB combination, or just pass it on, and not modify it into the wrong catagory. Since SFP has a Tyros device list it should refer to it when determining sounds.. This is still a 'sore' spot.. Are we going to get device lists for all the instruments that are out there. I think not; this will alway be a rough spot, unless Andre comes up with a Device creator program, (which would be truly great)... I know my hardwares and libraries, I know where to go to get the sound I need. I would think other studio operatiors would too
How is one going to deal with these new super sound libraries, that have arpeggios, slurs, slides, etc.. I guess that would be a stage SFP leaves for the DAW.. But the fact is, when you're creating a piece you need to have 'what you see is what you get'.. I need to have the finished sound, with articulated, burps, chirps, squeaks, slides, arpeggios.. Otherwise I can't build on what is not audibly there.. That's why I go back/forth between Logic/SFP. A real rich string patch is going to inspire you to play and create totally different than a bland string sound..
It would also be nice if SFP had a MIDI event list so you could track down problems.. When an instrument is bare, (no containers or processes working) that the midi list would display that.. When you add a modifying container, or process, the event list should reflect that. We need mute containers, and mute notes, to further isolate snafu's..
There has been a lot of discussion about SFP not having tracks.. But the truth is it is a track, it is just being modified by different parameters.. When you set up instruments in your DAW be they hardware or Virtual, you are going to set up certain effects and you always want it to go to the same track or channel strip. Otherwise, effects, eq, instruments are going to be jumping all over your instrument or DAW Mixer window. Making it impossible to mix..
SFP with it's dynamic allocation, throws all your DAW setup/effects out the window.. When you set up a song one always wants a certain instrument on a certain midi channel going to a certain device and to the same track in the DAW, otherwise you are constantly resuffleing.. This can be rectified by reserving channels, than what's the point of dynamic patches/channels in the first place?
The Import window should have the MIDI CHANNEL #,, that is far more relevent than what SFP Track# wants to assign.. it should show an event list, so you can double check what you are doing. For instance I always want my track configurations to follow Yamaha's protocal.. MIDI channel 11 is always bass..That way when there is a problem one can quickly track down the culprit. The arrange parameters should directly allow you to change MIDI channel, catagory, MSB/LSB, Program right from that window, not jumping around.. Others of use will follow BIAB, or Roland etc.. In fact I don't know of any studio, that doesn't keep a set order of instruments so they can quickly effect changes.
I want the track list in SPF to look exactly as the track list in Logic, so I know what's going on.
(OK ...I've calmed down now... I didn't mean for this to sound like a rant.... please don't take it that way, but I feel very passionate about the subjects, I brought up, Without this, SFP is becoming more abstract.. I want to master it like Logic and know that if I do A, B C and D - I will end up with E... I'm finding it hard, to grasp all the processes and feel secure I can arrive at the result I am looking for with SFP. And until SFP reaches that plateau, it will remain in the esoteric catogory. I love the esoteric about it, cause it can do no other software, but I want to feel more competent with it. I can use BIAB's 'generate song command' to create all the 'happy accidents' i want..
Admittedly this is my first stab at the beta, so perhaps I am missing a lot of points,, but it doesn't readily appear to be simpler, just different. This whole situation of global, shared, private, midi racks,, should just be boiled down to one thing.. Pick a sound source (virtual instrument, MIDI hardware), pick a MIDI Channel # pick a catagory, (So SPF knows the boundaries), pick MSB/LSB/Prog. Save that as a song or template so you can use the same setup again..
I have a set of control sequences already built into my Logic template.. So I can quickly grap, a piano, acoustic guitar, epiano, etc.. As the song develops, then I go in and perhaps pick a different song, and put the appropriate MSB/LSB/Prog.
This is one of the most frustrating aspects of MIDI hardware modules, is getting them to sound exactly the same each time you pull up a multi - channel patch to play .. I often struggle with Motif rack to get same sounds. Tyros is work too, Tyros has a limited number of effects as many hardware modules do, so the 9 effects DSP's have to be spread over the 16 midi channels.. If a new patch is called up and needs a DSP, it robs from another location, so that instrument looses some of it's original programmed sound..
If you really want to get into the nuts and bolts of it, you're gonna have to learn sysex, and send sysex commands to your boxes to totally and completely program them ... Sorry sysex - is where I draw the line.. And I don't think Andre wants to deal with that, and I know that I don't either.. Still it is one of the obstacles..
Also when importing MIDI files static into SFP, theres needs to be a 'leave articulations intact' button.. That is notes in extreme high or low octaves, should be left alone and not processed If you copy of paste a section the 'articulation notes' get copy/pasted too..
As it is now, when you import a MIDI trackstatic , the first thing SFP tells you it is transposing out of range notes, thus destroying all your articulations you worked so hard to put into your original MIDI sequence.
As it is now,, I strip off the high articulation notes, import into SFP, export back to Logic, then re-add articulations, sometimes having to create more to deal with the changes SFP made.
Thu, 2013-09-12 - 08:48 Permalink
Hmm. Most, if not all issues boil down to these three points:
No need to argue, I will look into this. I already suspected the import to misbehave.
Except for 3, which is impossible, unfortunately. For most libraries I've seen, articulations are just 1 octave below the playing range, some even closer. Some even an octave above. That's impossible for Synfire to tell apart from music. Unless it already knows the exact pitch range of the particular sound.
I will check if a combination of "Don't Transpose" on import and "Strip Take Outside Range" after import would make sense. Or some single switch somewhere.
For you other questions, please read next post.