Sfz vst SFZero

[Jack Winter]

Also with LinVst, I changed so much of it at various stages that I had no real choice but to tear down the existing files and upload the newer files because I'm not going to edit existing files for hours on end just so the github files match the ones I've already got but all of the not so large changes since have been done with just editing the existing files and I'll keep doing it that way.

I'd second falktx opinion. The delete/upload of files, makes it really hard to follow what you do in linvst... Not that I want to complain as I'm grateful for your work on it, but it's really a pain trying to follow the changes to the code base. If you'd use branches, merge, commit and push, you'd make it so much easier for us that are interested to follow to changes, and who knows even to contribute code. The way you have been doing it before, is discouraging for anyone that would like to follow code changes and to contribute!

But in the end, big thanks for your work on it!

[Jack Winter]

Also with LinVst, I changed so much of it at various stages that I had no real choice but to tear down the existing files and upload the newer files because I'm not going to edit existing files for hours on end just so the github files match the ones I've already got but all of the not so large changes since have been done with just editing the existing files and I'll keep doing it that way.

I'd second falktx opinion. The delete/upload of files, makes it really hard to follow what you do in linvst... Not that I want to complain as I'm grateful for your work on it, but it's really a pain trying to follow the changes to the code base. If you'd use branches, merge, commit and push, you'd make it so much easier for us that are interested to follow the changes, and who knows even to contribute code. The way you have been doing it before, is discouraging for anyone that would like to follow code changes and to contribute!

But in the end, big thanks for your work on it!

[ubuntuuser]

Also with LinVst, I changed so much of it at various stages that I had no real choice but to tear down the existing files and upload the newer files because I'm not going to edit existing files for hours on end just so the github files match the ones I've already got but all of the not so large changes since have been done with just editing the existing files and I'll keep doing it that way.

I'd second falktx opinion. The delete/upload of files, makes it really hard to follow what you do in linvst... Not that I want to complain as I'm grateful for your work on it, but it's really a pain trying to follow the changes to the code base. If you'd use branches, merge, commit and push, you'd make it so much easier for us that are interested to follow to changes, and who knows even to contribute code. The way you are doing it at the moment, is discouraging for anyone that would like to follow code changes and to contribute!

But in the end, big thanks for your work on it!

Yes, I'll agree about github.

I'm not exactly a github fan to be honest.

Why isn't there an official linux version of github desktop?, who knows.

[Jack Winter]

I don't use any github client. Just git pull | branch | commit | merge | push | etc. All pure command line. And I must say at first I found it somewhat a pain to create and merge topic branches, but by now I far prefer this work flow...

[ubuntuuser]

github is just one of many git hosts out there, forget about "github client", what we mean here is to learn how to use git and not github specifically.

There are a lot of tutorials out there, for example:
https://www.sitepoint.com/git-for-beginners/
https://blog.udacity.com/2015/06/a-begi ... orial.html

git is just one of many versioning systems out there, but likely the best.
you can use git for more than just code - if the files are written down in text/readable format, git will work nicely to track changes, revert stuff, collaborate in teams, etc etc.
the learning efforts pays off greatly in the end.

I know how to use github at least in a basic way but some things just seem awkward and clumsy.

I mentioned forking a particular branch and here is the answer https://stackoverflow.com/questions/922 ... -in-github

Now if someone wants to follow 15 steps just to fork a branch then ok, but I think github could make it simpler very easily.

Why github doesn't provide a linux github desktop version if they are providing windows/mac versions is a bit mystifying (how many linux programmers use github?)

I don't use the github desktop but was trying to to fork a particular branch (see link above).

github might have features for teams etc but small projects don't always need them.

But github does have some good features for projects and teams and other things.

[ubuntuuser]

Getting back to SFZero,

I tested the memory using htop and Reaper with the Salamander Grand Piano sfz (over a gig I think).

https://freepats.zenvoid.org/Piano/acou ... piano.html

Without the disk streaming the memory used was around 2.5 gig and with the disk streaming version it dropped to around 450 mb.

[Michael Willis]

Hi ubuntuuser, thanks a lot for working on this! I finally got around to trying this with Virtual Playing Orchestra. The basic sounds are working just fine. I found that usage of SFZero is much more simple than LinuxSampler, both in operating the plugin, and the resulting signal routing connections (which ended up being a big tangle with LinuxSampler's 32-channel audio output). I did notice that SFZero logs some warnings about unsupported opcodes, which prevents some of the more involved use of VPO:

Code: Select all

ampeg_attackcc1, gain_cc1

These opcodes are used in some of the SFZ files to make the modwheel interpolate between a fast attack and slow attack sound. This works correctly on LinuxSampler, but Sfzero seems to play both samples at full gain.

Code: Select all

pitch_random, amp_random

VPO uses these as an attempt to naturalize the sound a little bit.

Code: Select all

seq_position, seq_length

I think these are related to some kind of round robin feature, like upbow vs. downbow on the strings.

Code: Select all

eq1_freq, eq1_bw, eq1_gain, eq2_freq, eq2_bw, eq2_gain

VPO uses EQ parameters to adjust certain frequency bands, probably to make some of the instruments sound less harsh.

Out of all of these, the ampeg_attackcc1 and gain_cc1 are most important to me. I'm even willing to contribute code to SFZero in order to support them. What would be a good way to collaborate on this? I hate to belabor a point that has already been discussed, but I'm not sure how to jump in with the existing repo convention of deleting then adding files to update them. I'm afraid that merging in any changes would be difficult and would possible result in losing code changes from one person or another.

[ubuntuuser]

Hi ubuntuuser, thanks a lot for working on this! I finally got around to trying this with Virtual Playing Orchestra. The basic sounds are working just fine. I found that usage of SFZero is much more simple than LinuxSampler, both in operating the plugin, and the resulting signal routing connections (which ended up being a big tangle with LinuxSampler's 32-channel audio output). I did notice that SFZero logs some warnings about unsupported opcodes, which prevents some of the more involved use of VPO:

Code: Select all

ampeg_attackcc1, gain_cc1

These opcodes are used in some of the SFZ files to make the modwheel interpolate between a fast attack and slow attack sound. This works correctly on LinuxSampler, but Sfzero seems to play both samples at full gain.

Code: Select all

pitch_random, amp_random

VPO uses these as an attempt to naturalize the sound a little bit.

Code: Select all

seq_position, seq_length

I think these are related to some kind of round robin feature, like upbow vs. downbow on the strings.

Code: Select all

eq1_freq, eq1_bw, eq1_gain, eq2_freq, eq2_bw, eq2_gain

VPO uses EQ parameters to adjust certain frequency bands, probably to make some of the instruments sound less harsh.

Out of all of these, the ampeg_attackcc1 and gain_cc1 are most important to me. I'm even willing to contribute code to SFZero in order to support them. What would be a good way to collaborate on this? I hate to belabor a point that has already been discussed, but I'm not sure how to jump in with the existing repo convention of deleting then adding files to update them. I'm afraid that merging in any changes would be difficult and would possible result in losing code changes from one person or another.

Yes, it's missing some opcodes and it would be great if you could contribute.

Maybe I could edit in the changes directly to the SFZero that I have on my github or if you don't want to do that then there might be other ways.

Just get in touch with me here or maybe even at github.

[Michael Willis]

Yes, it's missing some opcodes and it would be great if you could contribute.

Maybe I could edit in the changes directly to the SFZero that I have on my github or if you don't want to do that then there might be other ways.

Just get in touch with me here or maybe even at github.

To get started I'll need to know how to build it. I haven't used Juce beyond just a cursory glance at the file structure made by the new project wizard. I was hoping to see some kind of makefile in the repo, but it looks like maybe the SFZero.jucer file possibly serves a similar purpose. Do I need to open the project with Projucer?

I find it curious that the repo is called osxmidi/SFZero, which would seem to indicate that you were originally targeting Mac OS, but your builds are for Linux. The reason bring this up is because sometimes I do development on a Mac laptop; will I likely be able to build it on the Mac without trouble?

I think that the easiest way for me to contribute would be to fork your repo, develop on my fork, and then issue pull requests. Will that work for you?

[ubuntuuser]

Yes, it's missing some opcodes and it would be great if you could contribute.

Maybe I could edit in the changes directly to the SFZero that I have on my github or if you don't want to do that then there might be other ways.

Just get in touch with me here or maybe even at github.

To get started I'll need to know how to build it. I haven't used Juce beyond just a cursory glance at the file structure made by the new project wizard. I was hoping to see some kind of makefile in the repo, but it looks like maybe the SFZero.jucer file possibly serves a similar purpose. Do I need to open the project with Projucer?

I find it curious that the repo is called osxmidi/SFZero, which would seem to indicate that you were originally targeting Mac OS, but your builds are for Linux. The reason bring this up is because sometimes I do development on a Mac laptop; will I likely be able to build it on the Mac without trouble?

I think that the easiest way for me to contribute would be to fork your repo, develop on my fork, and then issue pull requests. Will that work for you?

I'm quite often on a Mac.

The forks I've got are from a mac user and were for the mac, imprompt at github.

imprompt said that he forked from altalogix because it was for the mac as well whereas the original Steve Folta SFZero wasn't (as far as I can make out).

imprompt forked from altalogix and imprompt added disk streaming.

altalogix forked from Steve Folta the original author and altalogix did a bit of a makeover on the original code (which Steve Folta called unspeakable things to the code).

Basically altalogix separated SFZero into a plugin and a module and prettied up the code and made it work on with modern Juce versions and with the Mac.

So maybe if you got the projucer project files from imprompt's SFZero and SFZeroModule and open them on a Mac with Juce then that may be the way to go.

You could use my forks and then imprompt's projucer mac project files and just reconfigure things or just use imprompt's forks.

I've only made a few simple changes to imprompt's forks for Linux dealing mainly with the opening of the file browser.

I originally had altalogix's forks (SFZero SFZeroModule) but then imprompt added a disk streaming branch, so I tried forking imprompt's SFZero and SFZeroModule but it ended up being a disaster because github would not fork something with the same name (SFZero SFZeroModule) even though they were forks from different github sites (one being altalogix and one being imprompt) so then I just tried to fork just the imprompt disk streaming branch and add it to altalogix's fork which didn't end well, so I deleted the altalogix fork and just forked imprompt's and that worked out because imprompt had originally forked from altalogix just as I had originally, so all was ok.

The main thing with projucer is that it needs to find the inbuilt Juce module paths and the vst header path and the SFZero plugin and SFZeroModule paths.

The clone zip of SFZeroModule should be unzipped and then that unzipped folder renamed SFZero and then placed in the JUCE modules folder.

How to use projucer and set things up for Linux is here https://github.com/imprompt/SFZero

On the Mac it's similar but it's an XCode project.

On Linux projucer generates a linux makefile.

[folderol]

Just as a matter of interest, what happened to SF2? I never hear it mentioned anymore, and the (very few) soundfonts I have are all SF2

[ssj71]

@falktx - why not work with damo22 on his sfz project? I'd rather see that mature than more LS stuff tbh.

[Lyberta]

Hmm it looks like GUI doesn't correctly respond to a preset change. I've made a preset in Ardour for Salamander Grand Piano (yeah, I know it's the worst instrument to test presets with) and the plugin proceeded to consume pretty much all my memory without any visual indicator.