Posted
If I import a midi file with programs in it. SFP sometimes accurately names it, other times doesn't. (does SFP ignore MBS/LSB on import?). Cause the program number is usually correct. That is T4 pianos end with program 4 but will have as many MSB/LSB configurations as there are pianos.
It doesn't appear that SFP imports and exports the MSB/LSB correctly.
If I change the sound after importing a file , does the new program overwrite what SFP imported as the sound?
I was examining midi files further. Logic had programs in each midi track exported from SFP
On SFP export some tracks had three of the same program # in a row..
Other Tracks lost their program # and instead that three instrances of C-Press value 0 command
One track had two -8000 pitchbends when there was not pitchbend data in Logics files exported.
Other tracks had meta values 'bridge', 'chorus', or "#" Logic did have labelled markers,but these were not displayed in the final multi channel midi file exported from Logic
When I imported Logic multifile into SFP 7 tracks had MSB?LSB values. but when SFP exported these only two tracks had the MSB/LSB values had these were wrong. - thus rendering the wrong program.
thanx
Sun, 2012-08-05 - 21:46 Permalink
Synfire uses MSB/LSB/PGM data as a hint only to identify the right sound. It does not preserve these physically in its track data. This would clash with the internal sound selection.
Be sure you have the desired sounds ready in an arrangement, then use the import with my private sounds option. Synfire will duplicate the arrangements sound properties and use them for the imported midi file.
Mon, 2012-08-06 - 01:08 Permalink
Synfire should recognize and use the MSB/LSB/PGM data as the patch you want to use, otherwise I wouldn't have gone to the bother to put it in the MIDI file (and it is a bit of work). In fact Synfire should honor, use and export any CC data that was inported in.
It would make life so much simpler for us hardware users, (it might be interesting to take survey of what owners use for sound generation (hardware, Korg, Yamaha, Virtual Instruments). . If SFP has a device description, you would load that first and then import mide file.
If you don't have a device description, then user must supply instrument name. If your device is a direct mode, then tracks should stay on assign MIDI and put the MIDI channel as part of the name.
As elegent as the device list is, it's future is murky, who is going to create device descriptions for each and every instrument out there?. I fiddled around with it for days and could not create one. Andrew kindly created one for me, but you guys don't have the means, time to create devices for all hardware, and VI's out thre , and if a user can't get SFP to do what they need quickly, they do a work around, (switch sound, even application etc.)
It appears to me, SFP imagines it users as having tons of virtual instruments, and does a great job trying to address it.
But most of us here, and musicians I know, - know the instruments in their studio. They know where to go for what sound. There should be some consideration for the user with a humbler set-up with the least amount of hassle.
I feel strongly that I should be able to get the same sounds in SFP with no trouble as I do in Logic. This means using all CC data imported with a midi track.
The patch of a brass instrument (there are 32 in T4) makes all the difference in the world as to the notes, orchestration and arrengement of what I create in the other tracks. I need to
I use a control sequence like the one included: see CC_setup.jpg Often I will include even more CC events, on occassion sysex, when I need to do something fancy. It would be nice if SFP could accomodate that.
Thanx..
Mon, 2012-08-06 - 16:22 Permalink
As elegent as the device list is, it's future is murky, who is going to create device descriptions for each and every instrument out there?
Nobody, because it is not necessary. You don't need them for every device. You can set all sound properties per sound and each project manually, if that is more convenient.
Device descriptions (DD) are for sample libraries and synths that have complicated bank selections, custom CCs, articulations, restricted playing ranges, and such. The purpose of a DD is to remember these properties for frequent or spontaneous use. Without a DD, it would be near impossible to work with orchestral libraries like EWQL, or VSL, for instance. You would fiddle for hours, investigating the user manuals and tech specs of your library. I've done that for various libraries and I really want to do it again.
The convenience of browsing and selecting sounds by name is only a nice byproduct. The main purpose is to maintain required meta information.
You want Synfire to render musical expressions that fit the restictions of different sounds. This can not be done without meta information. Otherwise you can go and play the music yourself as with every DAW. You being a human with a pair of ears, this should not be a problem. Synfire has no ears and no independent judgement regarding the role and capabilities of an instrument. It needs a DD to know how to play.
It appears to me, SFP imagines it users as having tons of virtual instruments
Most Synfire users do. The older MIDI based version was not successful. We are seeing a big increase in demand and satisfaction since we built the audio version. The biggest advantage being that projects are now self-contained and easy to save and resume.
There should be some consideration for the user with a humbler set-up with the least amount of hassle.
I see your point, but the basic sound selection you are talking of is not sufficient. Given the above requirements, how would that work? Synfire has some AI on board, but it is far from being able to read your mind ;-)
Synfire uses the MSB/LSB/PGM and sound/track names in a midi file as a hint for matching the most likely intended sound of your setup (or your model arrangement that you duplicated with "using my sounds…"). This may still occasionally show a weakness here or there (sub-optimal match), but overall, it is the best solution possible.