LinuxMusicians

Jack Winter wrote:

ubuntuuser wrote: 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 wrote:

Jack Winter wrote:

ubuntuuser wrote: 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!

Jack Winter wrote:

ubuntuuser wrote: 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!

falkTX wrote: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.

Michael Willis wrote: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 wrote: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 wrote:

ubuntuuser wrote: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?