Those ones all have the same chip in them so should behave pretty similarly. One annoying thing is that the input is only mono. I use the Beringer UCA202 to get stereo input for only a bit more cash.

I'm trying to build an abstraction that can read a text file consisting of a list of names of .wav files and put each of the .wavs into an array. I'm using [text] to store the contents of the .txt file and some simple counter stuff to iterate through it and send the names to the respective arrays.

I'm running into something really baffling with the [text get] object, though. If I click a message box with say, 2 in it, and that goes to the [text get], it outputs the third line. If the message box goes into a number box and then into [text get], like the help file for [text get] shows, it also works fine. However, if the counter sends the same number to [text get] it only outputs a bang. The counter just consists of the usual integer and [+ 1] objects, and also a [- 1] before the [text get] since I numbered my arrays starting from 1 but [text] counts from 0.

As far as I can tell, the 2 coming from the number box and the 2 coming out of the [- 1] object box seem like they should be the same thing. But the former correctly outputs the stored text line when the [text] object receives it, and the latter just makes the [text] output a bang.

Any ideas what the heck is going on?
Pictures of patch and test print output attached.

Thanks you two. I used oid's replacement for l2s and added just a tidge as it was adding a space at the end of the string and I didn't want that. I also had to update the corresponding preset opening subpatch to work with the different space character, and replace the spaces in the saved presets, but that was easy enough to do.

I have a pretty large patch that stores settings in a bunch of tables and uses textfile and l2s (from zexy) objects to load and save presets. Loading is working fine, but the l2s in the save function has started adding a backslash to the names of settings. Does anyone know why this would be the case and how to stop it? I built this patch a few years back, and have been revising it to make it functional as an abstraction, but even loading the stable version I saved before I started the revision now has the backslash added when I use the save function, which completely breaks it. I know this wasn't the case before since I was able to save a number of presets using the subpatch when I first built the instrument a few years ago, and those presets still load fine.

I've attached a picture of the subpatch. Output from the print objects I added look like this:

d: list reverbBypass 0
e: symbol reverbBypass\ 0
ef: symbol reverbBypass\ 0
f: add reverbBypass\ 0
c: symbol reverbBypass
b: symbol reverbBypass
a: reverbBypass

and the saved file looks like this for that line: reverbBypass\ 0;

I also tried just building a little l2s thing without all of the file saving apparatus and I also get the backslash there. See the second picture, in which clicking on the bang gives this:

postl2s: symbol testing\ this\ motherfucker
prel2s: list testing this motherfucker

The l2s object's help file says its default delimiter is a space, which is how it worked fine for me in the past. But now I get this backslash in there. I've tried setting new delimiters but I can't figure out how to set it to be a space. Other delimiters like a . or a zero character delimiter work fine like the help file shows.

Any ideas on how to get this backslash to stop showing up?

Hey everybody,

I'd like to get pure data working on my raspberry pi to run headless, open a patch, accept audio input, and send it on out to the worth.

I have a sabrent usb audio device, It works fine if I open a gui and load pd within it. Upon loading the gui Pd takes the sound card, is happy, and a very simple patch of adc->dac puts the audio out.

I can't get it working headless. I've followed every internet advice. I know this isn't the fault of pure data but of Linus Torvalds/the Linux community, but I'd like to plug in the raspberry pi, get it going headless on say, ring mod into some delay, and just go from there. But will this ever be possible? Please help.

I wiped the microsd card today, installed raspberry stretch, and that's what it runs on now.

Thank you.
A dying soul.

Does Camomile have this kind of functionality? I haven't played around with it yet but I've been thinking about getting some of my patches working in it to integrate into Reaper. I assume that if you render a project in a DAW with camomile that it can calculate the output in non realtime. Otherwise it would be quite limited. But again, I haven't tried this yet; I'm just hoping to in the near future.

All of these fft based solutions are closely related to what a vocoder is, though. They'll likely sound artificial and robotic without careful tuning. There's no real general purpose solution to these kinds of questions, as far as I can tell.

You might look at the I06.timbre.stamp.pd help file but try replacing the example sounds with piano and guitar samples and see what you get and go from there.

There's an object in the fftease library called dentist~ that lets you specify which partials to let through or block, which will let you do more radical editing of the spectrum of the guitar tone than an EQ. It won't get you to a piano sound but it might get you to something that's more plinky plonky out of the guitar.

There's a moog~ in ggee that sounds pretty nice to me

Okay here's another conundrum: the help file for threshold~ says that it triggers when it EXCEEDS the target value, which is why I have the .9999 nonsense in the adsr patch. Further testing suggests that it actually triggers when it HITS the target value. I'm attaching a small patch to demonstrate. Is this just an infelicity in the help file, or am I overlooking something?thresholdTester.pd

It's much nicer to have it bang on the target value, as I can use it like a signal-based select, rather than having to specify a target value that is vanishingly close to the actual end value of the attack segment.

Thanks for all the suggestions about this. I'm going to keep plugging away and report back when I find the fix, though I'll probably ultimately take th8a's suggestion of using tables for the envelope segments so I can eliminate the hacky way I'm using threshold~.

I've been building in lots of print and env~ objects to try to figure out where the exact problem is. I believe I've successfully determined that it's NOT the voice stealing or the threshold~ object. All the midi info seems to be getting routed to the right voices, and the decay segment seems to be playing correctly even in notes that get stuck on, which it's the purpose of the threshold~ object to trigger.

For some reason the midi off control seems to be sent to the envelope, but it isn't registering it. I can fake another off event with messages and the envelope releases normally at that point. I've been playing around with a slightly more complex synth patch that uses the same envelope abstraction, which is actually a little more helpful because it has multiple oscillators for each voice, and they do NOT all seem to get stuck on at once. In fact, the base oscillator seems to be the only one that gets stuck on, whereas the 2 suboscillators do not, which suggest to me that I might have screwed up the construction of how the oscillator patch interacts with the envelope. But I'm still only closer to figuring it out; I haven't had much time to mess around with it lately.

What do you want to do with it? That'll probably affect how you end up designing it.

You can get the audio either in through adc~ if it's external to your computer or readfs~ to play a file on the hard drive. Hook those up to env~ and you'll get the dB of the input. Do whatever kind of math you need to do on it to convert it into the range you want and then feed that into some kind of oscillator.. You could also just feed it into a mtof since the dB values will already overlap with a good chunk of possible midi note values.

Playin around, still pretty baffled. This behavior happens fairly infrequently, and is hard to reproduce on demand, but happens certainly enough that I'll encounter it a handful of times in any session of messing around with the synth. I wonder if maybe something external to Pure Data could be making it miss the midi note off event? The only thing I can see from looking at the adsr patch that would account for the behavior is not receiving the note off message to trigger the release, but I could be wrong. Sometimes it seems like it might happen more when the computer is under more strain, so maybe something with the midi to usb interface I use is responsible? Hard to quantify.

Also willing to take advice on replacing the slightly hacky way I'm using threshold~ with something more correct. Though I don't think the threshold~ object is contributing to the problem itself.

Hi guys. I put together an adsr envelope abstraction a while ago to get the functionality I wanted where each segment of the envelope could have its own specified exponential curve. It generally works great, except that when I play glissandi in the synth patch I'm building one note appears to get stuck on every time if I play up to amount of polyphony. I assume there's something going on with the voice stealing, but I can't exactly see what or how I could fix it. Y'all have any advice? I'm attaching the whole synth patch in case it helps to look at it in context. The abstraction is adsr.pd which references expLine.pd to make the curves.

Thanks for any help you can give with this!
Little Ringy.zip

Oh thank you! Boy that's a simple fix. I can't believe I didn't notice.

Here's the part of the patch that experiences the problem.
LFO Generator.zip

Huh, so this behavior seems to disappear if I take the guts out of the lfo1 subpatch and just have them in the top level patch. Now there's no noticeable difference in tone between the output of the former guts of the subpatch and a send~ and receive~ pair. Still curious if anyone has any idea what could have caused the problem in the first place and how I could avoid it. I'd rather have the guts in a subpatch to keep things visually simpler, but since this works I'll go with this for now.

I'm fairly new to Pure Data, though I'm excited by what I've learned so far. I followed this tutorial -- http://designingsound.org/2013/04/pure-data-wavetable-synth-part-1/ -- up through the second-to-last step (with some adjustments for things that didn't quite work when I followed them in the tutorial), and then began modifying it to add more modulation and other features I wanted. I'm currently trying to implement what I'm thinking of as "suboscillators" that will be able to be tuned in relation to the main oscillator, mixed in with it, modulate pitch and amplitude, and take their own envelopes. I also want the suboscillators to be able to take modulation from either of the two "LFO"s [in quotes since the first LFO actually outputs in the audible range] (adding a second to what's specified in the tutorial, along with additional layers of LFOs below them), so I've been moving things around and redesigning the patch a little bit, breaking it off and on, and trying to get it working again.

While working on this, I noticed a behavior that's baffling me: the signal of the first LFO appears to distort when sent out through send~ and then back in through receive~. If I connect the output of the LFO directly to dac~, it sounds fine. Sent through send~ and back through receive~ and then to dac~ and it sounds louder and there are some other frequencies seemingly present, as if it's maybe clipping a little bit. I thought that send~ and receive~ were functionally the same as just using connector cords, so I'm seriously confused by this. For the purposes of the patch, having the LFO signal distort is not good, so I feel like I need to figure this out before I go forward with the features I want to implement. Being new, I imagine it's something simple I'm overlooking.

Here's a link to part of the patch where the problem is occurring: http://imgur.com/a/GkRUI I haven't tested yet to figure out if other send~ receive~ pairs are causing distortion. Any clarification or ideas about why this is happening would be much appreciated.

[edit: There's also apparently an error message going along with this: "consistency check failed: signal_free 3" I thought it was some other part of the larger patch generating the error, but I copied just the LFO generator section to a separate patch to play with, and that message still appears in the console. The weird distortion with receive~ still occurs too.]