I'm not having much luck with the midipolyaftertouch opcode. Basically
kPea init 0.1
midipolyaftertouch kPea, 1, 0.1, 0.9
printk2 kPea
does not actually respond to polyphonic aftertouch messages. On the other hand, a manually coded rough equivalent
kPea init 0.1
kstatus,kchan,kdata1,kdata2 midiin
if (kstatus==160 && kchan==1) then
kPea = kdata2 * 0.007
printk2 kPea
endif
works fine. So is this a known bug in midipolyaftertouch ? I can't find any usage examples for midipolyaftertouch, besides those from the manual, so I'm guess hardly anyone used it... By the way aftouch gets the channel not the per-note after-touch (pressure), i.e. aftouch queries kstatus == 208 (and actually does work, but of course it's not per note). For the difference see this.
I'm using Csound version 6.13 beta from inside Cabbage 2.3.0 on Windows (because that's what ships with that version of Cabbage).
There's another opcode namely polyaft that actually works, following the documentation
kPea init 0.1
inote notnum ; note number
kPea polyaft inote, 0.1, 0.9
printk2 kPea
Looking at the C source for midipolyaftertouch it is actually indexed exactly the same way as for polyaft. So based on that I tried:
kPea init 0.1
inote notnum ; note number
midipolyaftertouch kPea, inote, 0.1, 0.9
printk2 kPea
and this actually works too.
In the MIDI API jargon, "MIDI controller [number]" (usually) means key/note [number]... unlike in world of DAWs where one uses e.g. "multiple MIDI controllers" to mean several keyboards, not several keys of the same keyboard... Also, Csound has a notion of multiple controllers in the latter/DAW sense, selected by the -M startup switch, although it calls them "MIDI devices".
The code example for midipolyaftertouch from the documentation can't possibly work unless you just try it with D0 as the key/note; insert joke about the broken clock here. Interestingly the documentation was written by the source code author for that opcode, so it wasn't a case of someone else misunderstanding the code...
Related
If I run the following command, I get a "virtual microphone" that's hooked up to a sink called "MicOutput". If I send data to "MicOutput", that data is then sent to the virtual microphone.
pactl load-module module-null-sink sink_name=MicOutput sink_properties=device.description="MicOutput"
pacmd load-module module-virtual-source source_name=VirtualMic master=MicOutput.monitor
I can get similar behavior if I replace the second line with:
pactl load-module module-remap-source source_name=Remap-Source master=MicOutput.monitor
The main difference I see is that the latency is lower.
But what's the difference? When would I want to use one, or the other?
My Research so far
I see these two files:
https://fossies.org/linux/pulseaudio/src/modules/module-remap-source.c (added in 2013)
https://fossies.org/linux/pulseaudio/src/modules/module-virtual-source.c (added in 2010)
Perhaps if I looked at the code hard enough I'd understand the answer. I wonder if someone happens to know the answer though?
module-virtual-source is not typically used. It's an example of how a "filter source" should be implemented.
Module-remap-source has much less overhead
Source: I asked the PulseAudio team. https://lists.freedesktop.org/archives/pulseaudio-discuss/2022-April/032260.html
So knowing the fact that HAL is considered "slow" I decided to rewrtite a small routine in my programm using direct register access. And I decided to see, what I have won. Surprisingly, I actually lost.
So the code is
this->chip_select();
HAL_SPI_Transmit(hspi, spi_array, 3, HAL_MAX_DELAY);
this->chip_deselect();
this->chip_select();
SPI1->DR = spi_array[0];
while (!(SPI1->SR & SPI_SR_TXE));
SPI1->DR = spi_array[1];
while (!(SPI1->SR & SPI_SR_TXE));
SPI1->DR = spi_array[2];
while(SPI1->SR & SPI_SR_BSY);
this->chip_deselect();
So first I send 3 bytes using HAL, and then the same 3 bytes using the registers and same SPI.
Using HAL, the "interbyte" pause is 0,848ms.
And using registers - 1.192ms
How come? Isn't doing things with registers supposed to be quicker?
P.S. The stm32 is l071, 32 Mhz, SPI is 16Mhz.
Ok, so my mistake is - this was done on Debug build with 0 optimisation. With optimisation the register method is faster. Question is how to see the assembly code in Eclipse.
i know this forum dislikes "open" questions like this, nevertheless i'd like somebody to help untie the knot in my head, much appreciated.
The goal is simple:
read a stereo 32bit 44100 S/s I2S signal from 2 adafruit sph0645 mics
create a wav-header and store the data onto an SD-card
I've been at this for a few days now and i know that this will be much more complicated than i originally thought. Main reason: signal quality. Like most tutorials on this subject the simplest "hello world" for these mics is a looped polling for I2S-samples. Poll, fill buffer, output via serial or write to SD-card. This returns a choppy, noisy, sped up version of RL-audio. The filling of the internal DMA-buffers can be seen as constant, but the rest is mostly chaos, so
how to i sync these DMA-buffers with the rest of my code?
From experience with the STM32 HAL i'd imagine some register which can be set to throw an interrupt whenever a buffer is full, or an event which can be sent between tasks via queues. Examples on this subject either poll in a main loop with mono an abysmal sample-rate and bit depth or use pages of overkill code and never adress what it does, "just copy and it works", not good. Does the ESP32-Arduino framework provide some way to to this properly? The espressif-documentation isn't something to look forward to, since some of their I2S interface functions don't even work (if you are researching this topic as well, you too might have noticed that i2s_read only returns zeros). Just a hint into the right direction would help, i'm writing my own code anyway. Interrupts? Events? Timers? Polling for full buffers? Only you might know.
have a good one, thx
Thanks to https://github.com/atomic14/ i now have an answer for a syncing-method which works very well. This method has been tried by https://esp32.com/viewtopic.php?t=12546 who also didn't fully understand what was going on: the espressif i2s-interface offers a flag stored in an event which is triggererd every time one of the specified dma-buffers has received a full set of data, ergo, is full. It looks like this:
while(<your condition>){
i2s_event_t evt;
if (xQueueReceive(<your queue>, &evt, portMAX_DELAY) == pdPASS){
if (evt.type == I2S_EVENT_RX_DONE){
size_t bytesRead = 0;
do{
//read data via i2s_read or i2s_read_bytes
} while (bytesRead > 0);
No data is stored in this queue, but rather a flag which can then be used to synchronize dma-filling and further buffering/calculating/sending the read data.
HOWEVER this only works if you install the i2s driver in a specific setup. Instead of using
i2s_driver_install(I2S_NUM_0, &i2s_config, 0, NULL);
in your setup, you can activate the "affinity" for events by passing a queue-handle and a lenght:
i2s_driver_install(I2S_NUM_0, &i2s_config, 4, &<your queue>);
hope this helps getting started, it sure did help me.
I am trying to get familiar with gem5 simulator.
To start, I wrote a simple program with
int main()
{
m5_reset_stats(0, 0);
m5_dump_stats(0, 0);
return 0;
}
I compiled it with util/m5/m5op_x86.S and ran it using...
./build/X86/gem5.opt configs/example/se.py --caches -c ~/tmp/hello
The m5out/stats.txt shows (among other things)...
system.cpu.dcache.ReadReq_hits::total 881
system.cpu.dcache.WriteReq_hits::total 917
system.cpu.dcache.ReadReq_misses::total 54
system.cpu.dcache.WriteReq_misses::total 42
Why is an empty function showing so much hits and misses? Are the hits and misses caused by libc? If so, then what is the purpose of m5_reset_stats() and m5_dump_stats()?
I would check in the stats.txt file if there are two chunks of
---Begin---
---End-----
because as you explained it, the simulator is supposed to dump the stats at dump_stats(0,0) and at the end of the run. So, it seems like you either are looking at one of those intervals (and I would expect the other interval to have 0 for all stats); or there was a bug in the simulation and the dump_stats() (or reset_stats())didn't actually do anything. That actually happened to me plenty of times, but I am not really sure as to the source of this bug.
If you want to troubleshoot further, you could do the following:
Look at the disassembly of your code and find the reset_stats.w and dump_stats.w
Dump a trace from gem5 and see if it ends up executing the dump and reset instructions and also what instructions (and how many) are executed before/after.
Hope this helps!
During the reading of PLC documentation (Omron CP1L PLC and CX-Programmer), there are some missing explanation. For example, it defines "Flag" as "a bit that serves as an interface between in*struction", does that mean flag is some sort of conditional Power Flow?
It gets more confusing with the terms "Differential Up/Down", "Carry Flag"? What are flags and what do they do in the ladder logic? Are they a simple or instruction to use or just a concept that I don't really need to program in ladder?
[EDITED]
Where to add / modify / delete the flag in an instruction? I open up the edit but flag isn't there.
Ok, this is a better question.
PLCs are like any program - data is stored as different types. Think of flags as interchangeable with the term "bit", "boolean", etc. They are very important.
If you have CX-Programmer, a much better place to get information is the Instruction Reference (Help --> Instruction Reference --> yourPLC). These show time diagrams of most of the instructions and how each of the parameters and flags operate.
For example, a basic timer (TIM) works by assigning it a value. If you use a BCD type 100ms timer and assign its SV (setpoint value) a BCD value of 300 then you have created a timer with a 30 second limit (300 x 100ms). When the timer turns on it will begin counting and the PV (process value) will start from 300 and count down. When the value reaches zero the timer's flag turns ON to indicate that it has expired. If the timer's number is, say T100 then you can use T100 as a contact in another rung of logic - it will be true when the timer's execution conditions are TRUE and the timer has expired.
Differentials (UP/DOWN) are special flags which are true for only one PLC scan (ie: they are true for one execution cycle only) when their input conditions change from FALSE to TRUE (ie:OFF to ON) for UP differentials, and TRUE to FALSE (ie:ON to OFF) for DOWN differentials. You would use differentials in cases where you wanted to perform an action the moment a given condition changes.
Flags can be used for almost anything. You can use them as general booleans in your own programs, they can be parts of certain operations (ie: the CY (carry) flag is used on arithmetic operations which result in a carry - other flags are used to indicate overflows or div/0 errors, etc).
Edit again : (to answer extended question).
A basic timer's completion flag is a contact with its number. Say I have a 100ms timer, T100, which turns on when contact 10.00 is on:
10.00 ___
|-----| |---------------------------------------|TIM|
|100|
| |
|#20|
|___|
Now, once 10.00 has been ON for two seconds, the timer will elapse and the flag for timer 100, T100, will turn ON. If I had another rung where
| T100 W15.00
|-----| |-----------------------------------( )
Then work bit W15.00 would be turned on when the timer elapsed and would remain on so long as the timer's input condition remained satisfied (ie: so long as 10.00 remains ON). Flags work in different ways for different things, however. Each operation can use them in different ways.
The example from the Omron Instruction Reference (Help -> Instruction Reference -> [select PLC]) looks like this :
Well very good explanation with example and the flags value can be found in memory area it is pure binary either 0 or 1, as i was read the documentation work-bit memory location changes as per timer type e.g TIM/TIMX or TIMH or TIMHX, both are BCD timers but unit for the timer changes.