@jameslo Hey, thanks for that! It attenuates them more than the vcf~ method... but between the overtones and noise, the string sound is still recognizable... and the range of the filter is so wide that normal speech ends up sounding very thinned. I'd assume you're supposed to be able to set the width of the filter range, but anything above 0 immediately opens a big notch.

@s.elliot.perez said:

@whale-av Do you ever find yourself unable to close or save a patch if you turn off DSP while using ASIO4All? This happens consistently, even when ASIO4ALL is working, and I have to do a force quit.

@whale-av Do you ever find yourself unable to close or save a patch if you turn off DSP while using ASIO4All?

I tried lowering the q to 10, but this didn(t seem to help.

I also tried setting an osc to be subtracted, but the osc sound ends up persisting.

Yeah, I'd be willing to put up with some latency- please share your method?

I have a violin that sends both audio and midi to the computer and am also using another microphone in the same vicinity. I'm trying to use the midi note value of the violin as a notch filter to filter out the sound of the string's acoustic vibration:

I can hear that this attenuates the sound a little bit, but not by that much. Any ideas for improving this? I tried adding additional vcf~ for overtones, but that didn't make a noticeable difference.

@whale-av

OK, after hours of messing with this, the solution is quite simple... as you can see in the screenshots of my previous post, the block size in Pure Data is 64 while the size in the ASIO4All settings is 1024. Making sure these values match (in the Presonus control panel too) and setting them to 512 seems to work (setting it lower doesn't seem to work, the webcam audio is probably holding the other devices back) . Thanks for giving me some ideas!

@whale-av OK, I tried raising latency t0 1024 and setting everything to 48k. The result is that it gets noisy sooner (in a rhythmic, pulsing way). Here are screenshots of my settings. See anything else that might be wrong?

I tried returning PD to 44.1k and turning off resample while leaving latency at 1024, but it's the same as the original problem....

@whale-av Just double-checked and no, it stays green when it glitches.

I just used the USBView app recommended by the ASIO4All documentation and it looks like all three of my devices have at least one line of "bmAttributes" where it says that "Synchronization Type = Asynchronous", which I guess means that they don't sync with my computer's clock and are thus causing this problem. Am I out of luck?

@whale-av Hey, thank you. It works well for about five minutes and then the sound gets glitchy/noisy for a couple of minutes bit before returning to normal for a while.

In the ASIO4ALL advanced settings, I have the following toggled on:

PreSonus AudioBox iTwo
---Out 2x 44.1kHz 24Bits
Logicool BRIO (webcam)
BOSS GP-10
---IN(GP-10)

*ASIO Buffer Size is 512 for everything
*Latency compensation is set to 32 samples in and out
*Allow Pull Mode is off
*Always Resample 44.1kHz<->48Hz is off (PD is running in 44.1kHz)
*Force WDM Driver to 16 Bit

Any idea what could be wrong? I guess I could try ditching the BRIO webcam's audio for a mic that goes into the Presonus if reducing the amount of devices from three to two would help.

This seems like a problem in general on Windows, but Pd still seems to give me the option to use Multiple Devices in the Audio Settings.

I feel like I've been able to do this before, despite the repeated console warning:

separate audio device choice not supported; using sequential devices.

but now when I try it I can only get the audio input of the first device. Is there any way to get both? If not, why is this option here? Is setting up some kind of virtual sound card to combine the different devices into one the only way of doing this? (and if so, what do you recommend?)

I downloaded iemlib_R1.17_win, but it doesn't contain filter~.pd, which is needed for objects like lp2c~.pd

Now, there is a filter~.c file in iemlib1/src, but without an .sln file I've no idea how to compile this.

(Btw, I'm trying to use iemlib for @JosephEoff 's noise reduction patch)

I'd like to be able to drive some noise filters based on the spectrum of an input sound and have the timing of the noise filters' changes line up with those of the input sound.

The [print~] object gets you all the values right away, but only into the console. Is there a way to get them in that format into a list?

All the patches I've looked at use tabwrite~/tabread~ with metro to output the data, and this is maybe slowed down further by the application of hanning windows. (having the normalized, nicely distributed output those afford would be nice though)

@jameslo @whale-av Thanks for your replies, very helpful. While we're here, how would you approach getting an average of several incoming values for Red, Green and Blue respectively?

What I'm trying below is:

1. route the list twice. Once to put it in one of four groups (so 0-8 go into one group, 9-17 in the next, etc. Then again via the [clone] object. (prepending the same value to the list for 2 routes doesn't seem very elegant)
2. [pack] the RGB values
3. {not pictured} send them to an averager abstraction and set it so that each incoming list's unpacked values go into a [f]->[+] loop to add them, which activates a bang when it's done in order to carry out the division. Do this for each value in each group.

Haven't done up to step three because this seems very arduous and you probably have a better idea.

@whale-av Thank you! Yeah, it works fine using a bunch of route objects and this can be done in an abstraction using your [loadbang]->[$1]->[makefilename %d] solution, but it'd be hard to do with [clone] since you'd want to send in a list starting with a number into the [clone] before the parsing even happens. And [clone] is nicer than having a bunch of abstractions and manually typing their arguments...

so yeah, I'll probably modify the outgoing osc messages in the future.

Hello.

I'd like to get an incoming osc message and, after using [oscparse]->[unpack s f], I'd like to be able to take that unpacked symbol, eg.

dmx/light/1/red

and separate it so I can get the values that are separated by forward-slashes, in particularl the '1' and the 'red' so I can use them to route the float value. Is there a way to do this? Or do I need to reformat my OSC message at the source?

@4ZZ4 @whale-av I get this same error message in the console (also Windows 10), but the input from the two devices is working. Is there some reason I shouldn't do this?

So if I'd alternate between writing to two different tables there on the right at every beat of the [metro], I'd have to time a switch between tables on the left accordingly. I figure switching arrays suddenly would also lead to snaps, so some kind of cross-fade...? but how to time it....

granular.zip

So I've been using some version of this patch (the main patch is gs.pd) for a while now for Granular Synthesis using audio files and it works well. I've adapted it here to take live input that continually refreshes (cf. the upper right of gs.pd), and it works, but sometimes there are random snaps in the sound. If I had to speculate as to what is causing this, I'd imagine it's the buffer changing in a part that is currently being read, but I'm not sure how to confirm this, or even what I'd do about it if I could. The heart of the synthesis is in grain-stream.pd, three of which are in [pd 3streams in the mid-lower-left of gs.pd. Any ideas? Maybe have it alternate reading into two buffers and have the grain-stream read only from the buffer that's currently not being written to? Sounds like that'd be tricky to coordinate timing-wise though.

@whale-av Hey, sorry I never replied- I just saw your reply now after I bought the instrument. I ended up getting the BOSS GP-10 as a MIDI interface for the instrument. I knew the GR-55, SY-300 and SY-1000 would work as well, but didn't know about the GI-20. Maybe it would've been more affordable...

Here are my notes. Happy to hear anyone else's experiences or ideas about how I can get the most out of this device:

1)The instrument has screws on the back that you can turn to increase/decrease the sensitivity of each string. I've adjusted these a bit with dealing with the problems mentioned below in observation 9)

2)The GP-10 also has some settings for more or less dynamic contrast. I've experimented with setting these differently, though setting "Dynamics" to 1 and "Play Feel" to FEEL 1 seems to be the best. Changing these doesn't seem to do anything for the problem in 9).

3)I have the GP-10 set to MONO mode, rather than poly mode so that each string outputs to a separate MIDI channel.

4. The output to separate channels works well if you do clear attacks with the bow (or use pizzicato of course). The attacks need to be clear whenever you switch to a different string. Raising the sensitivity (cf. 5)) allows you to have clear attacks that are still somewhat quiet.

5. As long as a note is sustained, you get continuously updated bend values, which can be combined with the original noteOn value to get exact pitches and perform glissandi. I combine the two values in Pure Data with math objects. noteplusbend.pd

6. The MIDI velocity value does not update continuously, but in PD I can use the velocity's value as a switch to allow the Audio-in (which also comes in through the GP-10's USB) to control the volume of the MIDI-activated note via [spigot].

7. Because attacks with the bow need to be clear, if you fade in a note very gradually with the bow, it won't be detected as MIDI.

8. By combining 6) and 7) I can construct patches in Pure Data so that a certain sound will play and be controlled purely by the Audio-input and that others will be activated by MIDI+Audio-Input. Eg. I can fade in a sound, crescendo with an up-bow and then attack crisply on the down-bow to activate other sounds.

9. There are some issues with stable pitch detection when playing double-stops (diads) on two neighboring strings. It seems when doing so that there's some interference. However, for some reason, playing smaller intervals (major 3rds or lower) seems to work better than larger intervals. And avoiding open strings helps as well.

10. The pitch detection of 9) could be ameliorated by removing the bend value from the equation, but of course glissandi/microtonality would be lost as a result.

11. The E string (the highest one) gives the quietest, least consistent output. Pitch detection suddenly falls off after the first octave.

@seb-harmonik.ar Thank you! Now if only I could figure out the magnification thing.