Ok, I see. I'll try tomorrow with chnset and report.
luis

- 13 Jan
- Joined Jul 2, 2020
- 8 discussions
- 38 posts
- In run on boot
Thanks for the useful tip - I was seeing the same problem where my Csound projects selected to run on boot would fail with a Segmentation fault.
I can confirm that upgrading to csound 6.18 from the link above has resolved this issue.
Cheers
- In run on boot
luis Is there any known issue with firefox?
no. If you see "Chrome" somewhere in our docs is mostly legacy
- In run on boot
Great I will make that the official release then
- In run on boot
fixed it, try again
giuliomoro P9.27 for Bela/CTAG
actually that's wrong. That's the pin for the switch, not the LED. The LED on Bela cape Rev B (the only ones ever available on the market) is not accessible through the headers. Rev C capes will have on-board LEDs and these will go on accessible pins. For now, you can change these lines in
Bela/core/PRU.cpp
to use a GPIO of your choice.const uint32_t userLed3GpioBase = Gpio::getBankAddress(1); const uint32_t userLed3GpioPinMask = 1 << 24;
- Edited
Hi
On “Lecture 3: Wavetables”, we learned we should avoid aliasing by avoiding harmonize we do not support.
This is how I’ve implemented that
(For now I’m following You tutorial on Desktop without bela device
https://github.com/shemeshg/LearningRtAudio/blob/master/libs/TestRtAudio/TestRtAudioLib/Components/OscWaveTableAddative.cpp
My Bella should arrive soon so it might look a bit different on real Bella
):for (unsigned int i = 1; i < harmoniesLevels.size(); i++) { if (((float)gFrequency * (i + 1)) > (sampleRate / 2)) { break; } gWavetable[n] += harmoniesLevels[i] * sin(fondamental * (i + 1)); }
* This is nice, but it is evaluated for every buffer, (Requires recalculating of the wavetable).
- In “Lecture 8: Filters” we sow it might be possible to just filter those frequencies,
Question:
- What type of filter would you choose,
- of what degree
- how would you choose the Cutoff frequency
- and What Q
assuming it is the correct path to take?
As far as I know, there is no opcode to interact with generic I2C devices, but it wouldn't be impossible to write one that does, perhaps on the blueprint of the Trill ones. While this would allow you to communicate with the sensors, you may have to implement some (potentially fairly complicated) device-specific routines in Csound to transmit and format/parse date going to/coming from the device.
Perhaps a better option for device with a non-trivial communication protocol is to get your hands dirty a bit deeper in C++ and port individual Arduino libraries each to a different opcode.@csounder I have found a piece of example code that Bernt had given me:
/***** Trill.csd *****/ ;------------------------------------------------------ ; Input from Trill sensors - Csound on Bela ; * Bernt I. Wærstad, Victor Lazzarini, Alex Hofmann ; ; This example shows how to read values from Trill sensors ; connected to the Bela. Go to bela.io/trill to get started ; with connecting Trill to Bela ;------------------------------------------------------ <CsoundSynthesizer> <CsOptions> </CsOptions> <CsInstruments> ksmps = 8 nchnls = 2 0dbfs = 1 instr 1 iNumTouches = 5 iTrillID = 0 kactiveTouches init 0 ktouchSizes[] init iNumTouches ktouchVert[] init iNumTouches ktouchHori[] init iNumTouches kactiveTouches, ktouchSizes, ktouchVert, ktouchHori trill iNumTouches, iTrillID printk2 kactiveTouches ktrig_v changed2 ktouchVert ktrig_h changed2 ktouchHori ktrig = ktrig_v + ktrig_h printarray ktouchVert, ktrig, "","Vertical:" printarray ktouchHori, ktrig, "", "Horisontal" endin </CsInstruments> <CsScore> i1 0 86400 </CsScore> </CsoundSynthesizer>