3 ms·

Thanks for answering! Assuming your original question was not rhetorical and was asked in good faith, other people who've used SFZero before the advent of LLM'

Thanks for answering! Assuming your original question was not rhetorical and was asked in good faith, other people who've used SFZero before the advent of LLM's made sure they understood juce::Synthesizer (despite its many warts, juce's public interfaces are well documented and represent a strong point) as this just defines a specific implementation, and either referenced the provided example or read the headers, which are pretty straightforward. It's great that the LLM was able to get you to where you wanted to be, and congratulations on getting your project to that milestone. Especially for not having worked in C++ before! But to the point of the person you were responding to, the LLM was not fulfilling a generally unmet need. Everything a professional or practiced amateur needs was there already.

williamcotton 2y ago
> > learning by reading documentation and tutorials > But to the point of the person you were responding to, the LLM was not fulfilling a generally unmet need. Everything a professional or practiced amateur needs was there already. But isn't this stretching the definitions of documentation and tutorials a little bit here? A demo app and a bunch of undocumented header files became documentation and tutorials with the assistance of an LLM.
- swatcoder 2y ago
  Perhaps. As an experienced audio developer, it's a distinction without a difference. We get used to reading code and deciphering how to use or improve it (wait until you start working with other's DSP code!), and some features and conventions of C/C++, like the segregation of declarations from definitions, make it especially self-documenting for those that are fluent in it. Having integrated SFZero myself (albeit to a deadend; it's very middling-to-poor), I was surprised to discover that there was not more explicit documentation when you announced it as the library you were referring to, specifically because I remember the work of integrating it was relatively trivial (maybe half a day or so). For a complete outsider to audio development, JUCE, C++, of course the LLM helped you get done what you needed to get done, far faster than you could have hoped otherwise. And that's great if you're just toying around. On the other hand, you absolutely would have sharpened your skills with all three of those things more had you the luxury to muddle through and force yourself to make sense of it all yourself. Assuming skills development is your goal (otherwise, you should be using different tools here! C++ and JUCE are not where to start if your personal goal is music making, synthesis, or MIDI), there's a balancing act between making sure you don't get discouraged and committing to the hard work of learning things in-depth. The LLM gave you a way to avoid feeling stuck and discouraged, and perhaps represents the difference between you sticking with the project or just throwing your hands up. But keep in mind the tradeoff that it implies for skill development and consider only turning to it when the frustration starts to get too high to bear.
  - williamcotton 2y ago
    The way I use LLMs is as a learning tool. Sure, it can get me unstuck when I add some error messages to the context, but I always take the time to have it explain things, e.g. the reference counted memory model of some of the classes in JUCE. I prompt for a personalized tutorial with the specific problem I'm working on as the subject matter. I'm also a C programmer and Max/MSP user so this syntactical stuff is mainly just different ways of managing the stack and the heap while turning MIDI into sounds!

williamcotton 2y ago

> > learning by reading documentation and tutorials > But to the point of the person you were responding to, the LLM was not fulfilling a generally unmet need. Everything a professional or practiced amateur needs was there already. But isn't this stretching the definitions of documentation and tutorials a little bit here? A demo app and a bunch of undocumented header files became documentation and tutorials with the assistance of an LLM.

swatcoder 2y ago
Perhaps. As an experienced audio developer, it's a distinction without a difference. We get used to reading code and deciphering how to use or improve it (wait until you start working with other's DSP code!), and some features and conventions of C/C++, like the segregation of declarations from definitions, make it especially self-documenting for those that are fluent in it. Having integrated SFZero myself (albeit to a deadend; it's very middling-to-poor), I was surprised to discover that there was not more explicit documentation when you announced it as the library you were referring to, specifically because I remember the work of integrating it was relatively trivial (maybe half a day or so). For a complete outsider to audio development, JUCE, C++, of course the LLM helped you get done what you needed to get done, far faster than you could have hoped otherwise. And that's great if you're just toying around. On the other hand, you absolutely would have sharpened your skills with all three of those things more had you the luxury to muddle through and force yourself to make sense of it all yourself. Assuming skills development is your goal (otherwise, you should be using different tools here! C++ and JUCE are not where to start if your personal goal is music making, synthesis, or MIDI), there's a balancing act between making sure you don't get discouraged and committing to the hard work of learning things in-depth. The LLM gave you a way to avoid feeling stuck and discouraged, and perhaps represents the difference between you sticking with the project or just throwing your hands up. But keep in mind the tradeoff that it implies for skill development and consider only turning to it when the frustration starts to get too high to bear.
- williamcotton 2y ago
  The way I use LLMs is as a learning tool. Sure, it can get me unstuck when I add some error messages to the context, but I always take the time to have it explain things, e.g. the reference counted memory model of some of the classes in JUCE. I prompt for a personalized tutorial with the specific problem I'm working on as the subject matter. I'm also a C programmer and Max/MSP user so this syntactical stuff is mainly just different ways of managing the stack and the heap while turning MIDI into sounds!