-
catkisser666
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.
-
catkisser666
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.
-
catkisser666
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.
-
catkisser666
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: reverbBypassand 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 motherfuckerThe 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?
-
catkisser666
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. -
catkisser666
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.
-
catkisser666
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.
-
catkisser666
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.
-
catkisser666
There's a moog~ in ggee that sounds pretty nice to me
-
catkisser666
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.