ccrma / chugins Goto Github PK

On latest commit [410741a] FluidSynth chugin fails as it searches for Chuck_Array8 and Chuck_Array4 from the include folder. Renaming these to Chuck_ArrayFloat and Chuck_ArrayInt fixed the compile errors.

Also received the error "struct Chuck_DL_Api::VMApi' has no member 'get_srate'. I am not sure about the new syntax for that.

consider generating makefile that build for universal binary, or maybe can be an option, or something easily toggle-able in the makefile

duplicate of ccrma/chuck#267

Would it be possible to attach a license to this repo? MIT is preferred.

Thanks.

chuginate should either work with Python 2 + Python 3, or fail when attempting to use Python 3.

From a user:

In python3 you get:
python bootstrap.py < chuginate.py > chuginate
Traceback (most recent call last):
  File "bootstrap.py", line 38, in <module>
    b64 = base64.b64encode(f.read())
  File "/usr/lib/python3.4/codecs.py", line 319, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte
makefile:6: recipe for target 'chuginate' failed
make: *** [chuginate] Error 1

changing the makefile line to be "python2" explicitly helps Make complete, but since chuginate itself is v. 2 I think it causes trouble on systems where 3 is the primary python install.

I realized that for the VST plugin I'm working on, I'll want to load 64-bit VSTs instead of 32-bit. Once I started compiling the chugin to 64-bit instead of 32-bit, my VST.chug is no longer recognized by ChucK. How do 64-bit chugins work on Windows? Is there hope for a 64-bit VST chugin on Windows?

the chuck console says undefined type 'VST'... when it previously didn't have a problem. By the way my preprocessor statements include

        __WINDOWS_MODERN__
        __PLATFORM_WIN32__
        __WINDOWS_DS__
        _WINDOWS
        WIN32
        _USRDLL
        NDEBUG

chuck code:

SndBuf b => VST vst => dac;
"special:dope" => b.read;

if (vst.loadplugin("C:/VSTPlugIns/64bitVST_x64.dll")) {
   <<< "success!" >>>;
} else {
    <<< "fail!" >>>;
}

while( true )
{
    0 => b.pos;
    200::ms => now;
}

Is this bug still happening? https://lists.cs.princeton.edu/pipermail/chuck-users/2018-May/008369.html
Should the ChucK installer have put ChucK in C:/Program Files/ChucK not C:/Program Files (x86)/ChucK?

I've tried placing the 64-bit VST.chug in C:/Program Files/ChucK/chugins and C:/Program Files (x86)/ChucK/chugins.

This is the chuck console output:

[chuck]:(3:SEVERE): | | | loading chugin 'VST.chug'
[chuck]:(3:SEVERE): | | | error loading chugin 'VST.chug', skipping
[chuck]:(3:SEVERE): | | | error from chuck_dl: '193'

Does 193 mean "ERROR_BAD_EXE_FORMAT"? https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
https://github.com/ccrma/chuck/blob/05913b160e3fe881e5fb79d21d1d59a9fd9d02be/src/core/chuck_dl.cpp#L1190

https://stackoverflow.com/questions/38579909/loadlibrary-fails-with-error-code-193

"Error 193 is ERROR_BAD_EXE_FORMAT, most likely meaning the file is corrupted, or it's a 32-bit DLL you're loading into a 64-bit process or vice versa. "

testing from command line:

chuck --version
chuck version: 1.4.0.1 (numchucks)
   microsoft win32 : 32-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

How do I get the 64-bit version installed? http://chuck.stanford.edu/release/ Update: I built chuck.exe from the 1.4.0.1 source and now chuck --version is

chuck version: 1.4.0.1 (numchucks)
   microsoft win32 : 64-bit
   http://chuck.cs.princeton.edu/
   http://chuck.stanford.edu/

Then I replaced the chuck/include in this repo with the newer 1.4.0.1 source and rebuilt my chugin as 64-bit. However, it's still not being loaded due to the 193 error.

just figured out that signals connected to the right input of GVerb always come out dry, doesn't matter the settings in use.
Does GVerb want mono signals as input?
If so, we should correct the example that uses adc => GVerb gverb

simple example:

GVerb gverb;
Impulse impulse;
//impulse => gverb.chan(0); // this works
impulse => gverb.chan(1);  // this doesn't work properly
gverb => dac;
while (true)
{
    impulse.next(1);
    second => now;
}

// this is a special offset reserved for Chugin internal data
t_CKINT vst_data_offset = 0;

class VST
{
// omitting some stuff for brevity
protected:
    Chuck_String* myChuckString = new Chuck_String("hello");
public:
    Chuck_String* getParameterName(int index) {
        myChuckString->set("world");
        return myChuckString;
    }
}

CK_DLL_MFUN(vst_getparametername)
{
    t_CKINT index = GET_NEXT_INT(ARGS);

    VST* b = (VST*)OBJ_MEMBER_INT(SELF, vst_data_offset);

    RETURN->v_string = b->getParameterName(index);
}

This doesn't compile:

1>VST.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl Chuck_VM_Object::add_ref(void)" (?add_ref@Chuck_VM_Object@@UEAAXXZ)
1>VST.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl Chuck_VM_Object::release(void)" (?release@Chuck_VM_Object@@UEAAXXZ)
1>VST.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl Chuck_VM_Object::lock(void)" (?lock@Chuck_VM_Object@@UEAAXXZ)
1>VST.obj : error LNK2019: unresolved external symbol "public: __cdecl Chuck_Object::Chuck_Object(void)" (??0Chuck_Object@@qeaa@XZ) referenced in function "public: __cdecl VST::VST(void)" (??0VST@@qeaa@XZ)
1>VST.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl Chuck_Object::~Chuck_Object(void)" (??1Chuck_Object@@UEAA@XZ) referenced in function "int public: __cdecl VST::VST(void)'::1'::dtor$10" (?dtor$10@?0???0VST@@qeaa@XZ@4HA)

I found that if I modify the chuck source code in a few ways it compiles and my chuck code works as desired. my_patch.txt I'm attaching my_patch.txt which is actually a git diff file. Rename it to my_patch.patch. What can be done to avoid changing the chuck source in these ways? What's the right way to return a string?

as per Discord discussion;

spencer: "in general think something like this will help make sure the official distribution is relatively high quality

• all chugins in ccrma/chugins compile on Mac/Windows/Linux
• clear or no external build requirements (e.g. extra libraries, dependencies, are all easily obtainable for Mac/Windows/Linux)
• related to ^ should be able to build on anyones system (setting a ccrma/chugins build pipeline up w Github Actions would help a ton w this)"

also, what is a good place to put the large volume of faust2ck chugins?

@spencersalazar @nshaheed @celestebetancur

It looks like it is not up to date with some of the new chuck API functions, also the build script should not try to create the folder /usr/local/lib/chuck.
After updating this two things a new error in the final linking for libsndfile:
relocation R_X86_64_PC32 against symbol `sf_errno' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
@DBraun :)

I've made good progress getting JUCE working in a chugin. I can build VST.chug and it includes all my references to JUCE and VST stuff. The problem is that I'm using CMake rather than make, and I think it's preventing exported functions from working inside ChucK.

This is my test chuck code:

SndBuf b => VST vst => dac;
"special:dope" => b.read;

// give it a valid VST DLL path, not this fake one
if (vst.loadplugin("C:/path/to/vstplugin.dll")) {
   <<< "success!"  >>>;
} else {
    <<< "fail!"  >>>;
}

while( true )
{
    0 => b.pos;
    200::ms => now;
}

The ChucK console says class 'VST' has no member 'loadplugin'.

If I remove the lines about loadplugin, then the special:dope plays in the DAC because my VST class is programmed to pass-through audio if a plugin hasn't been loaded yet.

So I think I'm very close. I just wonder why my exports aren't working. I started with the Binaural example and added functions to it. Could you catch a mistake in my vst.cpp or speculate what's going wrong with my build process?

Thanks!

VST.txt

Suggested by @celestebetancur

In the context of #64, this makes a lot of sense - it serves as a single point of truth that you can pull from rather than the current policy of copy+paste the headers from chuck-core. That's fine if the assumption is that chugin repo is the single source of truth, but if we move to the chugin repo having stricter standards and encouraging people to make their own repos otherwise, we need a more central way to unify headers.

The example code for the perlin chugin requires chugl. Should probably split out perlin-test-gfx.ck and perlin-test.ck for people who do not have access to chugl.

The FluidSynth chugin no longer works on Linux (and I think OSX too). After much frustrating bug hunting, I found that it's because the linker is called incorrectly. The reference to -lfluidsynth needs to be at the end of the linking command:

gcc -shared -lstdc++ -o FluidSynth.chug FluidSynth.o -lfluidsynth

Also, someone (me?) seems to have commented out part of the FluidSynth.cpp code...

I have it fixed in my fork and I could do a pull request but I have some other stuff in there that isn't ready for prime time...

The template generated by chuginate should document the generated class / functions using doc_class / doc_func to promote documenting chugins generated using this script.

Then add cool features like auto-chuginating C++ classes, ChucK Chugens, etc.

chuck 1.4.2 appears to have broken Spectacle and Multicomb (RNG) by undefining RAND_MAX.

Seems like an opportunity to modernize and decouple. Both chugins want a rand2f function.
Here's a simple+modern+portable one.

#include <random>
float rand2f (float min, float max)
{
    static std::mt19937 s_mt;
    static std::uniform_real_distribution<float> s_dist(0.f, 1.f);
    float x = s_dist(s_mt);
    return min + x * (max - min);
}

At row 121 we have:
`
float setDrive(float d)
{
m_drive = dB2lin(d);
return m_drive;
}

float getDrive() { return m_drive; }

`

I think the 2 should use the same value
I had a the following scenario:
ABSaturator saturator[2]; 35 => saturator[0].drive => saturator[1].drive;

and it took me 20 mins to figure out why they sounded different and why were spitting out what it seemed were random values :)

Include an example .ck file in the project generated by chuginate. Again, this promotes documenting by example, and also makes it very easy to confirm that a generated chugin is working. E.g.:

chuginate foo
cd foo
chuck --chugin:foo.chug foo-test.ck

Tested on Ubuntu Studio 16.04 64bit - ChucK 1.4.0.0

Hi,
I found out that once the size of the array in Wavetable has been increased, there's no way to use an array smaller than the last one in use without having issues.
Let's say Wavetable is initialized using an array of size 512, then in the program you pass to setTable() an array of 1024, then going back to an array of 512 doesn't scale back properly (if that makes sense).

I think the issue could be the following, in Wavetable.cpp on line 156 we have:
table_size = (int)userArray->capacity();

while it should probably be:
table_size = (int)userArray->size();

NHHall and Ladspa chugins are present in the repo and were present in osx builds up until recently, but now are missing from the osx build. I haven't looked into this carefully yet; those are simply two that I use in LiCK and found break the build as of chuck version 1.5.0.0.

$ cd chugins
$ make osx
...
CHUCK_STRICT=1 make -C Wavetable/ osx
clang++ -mmacosx-version-min=10.9 -D__MACOSX_CORE__ -I../chuck/include/ -arch x86_64 -fPIC -O3 -Werror -c -o Wavetable.o Wavetable.cpp
clang++ -mmacosx-version-min=10.9 -shared -lc++ -arch x86_64 -o Wavetable.chug Wavetable.o

$ sudo make install
Password:
mkdir -p /usr/local/lib/chuck
cp -rf ABSaturator/ABSaturator.chug AmbPan/AmbPan.chug Bitcrusher/Bitcrusher.chug KasFilter/KasFilter.chug MagicSine/MagicSine.chug FIR/FIR.chug FoldbackSaturator/FoldbackSaturator.chug PanN/PanN.chug PitchTrack/PitchTrack.chug GVerb/GVerb.chug Mesh2D/Mesh2D.chug Spectacle/Spectacle.chug Elliptic/Elliptic.chug Sigmund/Sigmund.chug ExpDelay/ExpDelay.chug Overdrive/Overdrive.chug Multicomb/Multicomb.chug PowerADSR/PowerADSR.chug WinFuncEnv/WinFuncEnv.chug WPDiodeLadder/WPDiodeLadder.chug WPKorg35/WPKorg35.chug Binaural/Binaural.chug ExpEnv/ExpEnv.chug Perlin/Perlin.chug Random/Random.chug Wavetable/Wavetable.chug /usr/local/lib/chuck

$ cd ../lick
$ chuck --loop &
$ chuck + import.ck
...
[chuck](VM): sporking incoming shred: 1 (import.ck)...
"LiCK  Library for ChucK." :(string)
"Copyright (c) 2007-2023 held jointly by the individual authors." :(string)
"Licensed GNU General Public License (GPL), version 3 or later." :(string)
[chuck](VM): sporking incoming shred: 2 (BinaryFunction.ck)...
[chuck](VM): sporking incoming shred: 3 (BinaryPredicate.ck)...
...
[chuck](VM): sporking incoming shred: 348 (Golden.ck)...
[Hall.ck]:line(32): undefined type 'NHHall'...
[Hall.ck]:line(32): ... in declaration ...
...
[chuck](VM): sporking incoming shred: 436 (Hat.ck)...
[Ladspa.ck]:line(26): undefined type 'LADSPA'...
[Ladspa.ck]:line(26): ... in declaration ...
[Caps.ck]:line(25): undefined type 'Ladspa'...
[Caps.ck]:line(25): undefined super class 'Ladspa' in definition of class 'Caps'
...