Hi,

I'm printing text to a LCD 1602 with [print( messages through [comport], and a message takes about 2 seconds to appear on the LCD, when it's seemingly instentaneous from the Arduino serial console. Why is that? (I'm on lubuntu 18.04)

For the moment what I do is print with a command through [shell]

echo "Hello!" > /dev/ttyACM0

Which works nicely.

Thanks @jyg, it sounds cool, I'll check it out !

Oh okay, thanks for the answer. That's what I was afraid of. Unfortunately I have very little coding knowledge, none in Tk/Tcl.

There was the [pop] external from iemlib, but it's not in the iemlib folder, I don't kow why, And it's no good for me anyway, because I use text also to edit parameters live, I use it as a sort of sequencer editor, so that the file where I save my multi-track sequence also becomes the gui.

gio.

Hi,

Is there a way to resize and reposition a [text] window, like you would do using [relocate( with a normal pd window ?

Thanks

@jancsika, it would be t_sample, but I had to pause my little expriments. Thanks guys, I hope to be back at it in two weeks and nail this thing or come back with better questions.
@Nicolas-Danet you're in Montpellier, awesome! I will contact you soon I'd love to talk to someone who knows this stuff, it can be hard to learn on your own.

Hi ! I’m trying to write my first external, and have studied the externals-howto. I understand, for example how the pan~ example works (I think, I'm a noob in C), but in my case I'm confused:

I want to implement a recursive algorithm, I need to copy the inlet vector into an array A perform some operations, copy the restult in array B, swap arrays, and start over again several times until I can finaly copy one of the arrays into the outlet vector.

How do I have to treat these arrays in the code? should they be of type t_sample?
In the perform section should I treat them as the inlets and outlets?

t_int *foo_perform(t_int *w)
{
  t_sample  *in =    (t_sample *)(w[1]);
  t_sample  *out =    (t_sample *)(w[2]);
  t_sample  *a =    (t_sample *)(w[3]);
  t_sample  *b =    (t_sample *)(w[4]);
  int          n =           (int)(w[5]);

@paulspignon Wow that’s crazy ! What were you working on if I may ask ?

About music applications, do you know what the guy meant?
Seems to me you can acheive a lot of the same stuff as fft, but with different sounding artifacts ? That could be interesting.
Also, since you can acheive convolution, it could greatly improve performances of say partitionned convolution algorithm I don’t know

Anyway, I really hope we can prove this Signal Processing Guru wrong!

@jancsika Take a look at this one:
hutchins_paper_2.PDF

@jancsika
for the theorem itself you there are good ressources here and there for example:
discrete walsh hadamard transform on Mathworks.com
Wikipedia page

I didn't find much on sound specific usage except for this old paper hutchins_paper_1.PDF from Hutchins in... 1975. He is cited in Roads book. Very interesting

fwth.pd
The walsh-Hadamard transform is similar to fourier transform but works with square waves instead of sinewaves, which I find very interesting. I discovered it in Curtis Road's fantastic book "The Computer Music Tutorial" and since then got obsessed with it.
One big advantage of the Fast Walsh Hadamard Transform, is that it's much faster to compute than FFT since it only works with real numbers.

So I made this patch to demonstrate the idea with filtering. The core of it is based on a C code I found here: https://github.com/bvssvni/fwht/blob/master/fwht.c

This is just proof of concept. I'd love to make it real time but don't quite know how. Anybody?
I think this deserves a pair external that could be used like [rfft~] and [rifft~].
The C code for the algorithm is actually quite simple. I just don't know how to do all the wrapping.

Won't be much help but instead of zexy/z~, you can use delread~ or vd~ with a [block~ 1] to operate at sample level. I'd love to see this drum implemented !

Hello,

I made a little abstraction based on the first freeze patch ralph posted which I love for its simplicity.
What I realy needed was something that produces warm textures, so I naïvely implemented Paul nasca's idea of randomizing the phase. I didn't think it would work but it does (with large block) and it sounds realy good!

substance~.pd

I have a question but first I have to explain what I tried to do:

To continue with this very naïve version of the PADsynth, I wanted to record a sample out of the output that would be naturally looped, but I didn't manage to do so, this is from Paul Nasca's description of his algorithm:
"This algorithm generates some large wavetables that can played at diferent speeds to get the desired sound. This algorithm describes only how these wavetables are generated. The result is a perfectly looped wavetable".
What I did was to put a [once] under a [bang~] and write the sample in a table the length of the block~. From my limited understanding of fourier transform I thougth that a hole window would produce a periodic signal.

What should I do to produce a looping soundfile? Is there a problem with the overlapping perhaps?

cheers

Allister

resize does create a "crackle" in my experience too.
One work around in your case perhaps would be to use delwrite~ and delread~ in aloop, something like this: liveloop~.pd
When you call this abstraction you need to specify the buffer size in ms which will be your maximum loop length.
I'm not exactly sure what you want to do but I hope this helps somehow

wendy.pd
wendy-help.pd

[wendy] maps incoming notes onto scales constructed around equaly divided ratios that can be other than 2:1 (the octave), allowing for example pure fiths, at the cost of an imperfect octave, a cost which I'll gladly pay. As Wendy Carlos said: "That's one of the things you aren't suppose to do, which is exactly why I did it!"

It can be used to have any edo scales if desired

see help file for more info

Cheers

Allister

vdisk~-help.pd
vdisk~.pd

vdisk~ uses [readsf~] in conjunction with [block~] and [tabwrite~] to read a file from disk at any pitch/speed.

Usefull for situations where you need to load very quickly any soundfile from any folder and want to read them at any pitch.

I made this because I needed it and some externals such as [sfread2~] from moonlib tended to crash pd on my system, so I decided it wasn't reliable.

You're welcome!
You may also write pairs of values (for example pitch + velocity) with the ":" symbol like 62:120

All this is just an arbitrary protocol I've set up, I hope it makes sense

@Jona , Here are some examples:

1: I just write series of zeroes and ones and then do a [select 1] to trigger samples and stuff
2: I write gain values
3: I write notes or frequencies, such as 60 61 65 ...
4: I use the second outlet to have duration value (simply a time until next beat) and read a sample for that period of time

But then you can use it in any way you like

Hi!

Is this what you're looking for?

launchpad_polytouch.pd

tuplex.tar.gz

The tuplex abstraction is a sequencer that works on the principle of tuplets in music theory, that is to say division of a time unit.;
It works around a [delay] object that is periodicaly syncronized to a master metro, so as to never go noticeably off-beat even with low precision.

It allows to write rythms as it follows: 16(1 0.8 1);
This is relative to the metro time setting and means that a period of 16 metro time units is divided into 3 beats.

You can also write 16(1 0.8 (1 1)), which means that the third beat itself is divided by 2

You can have a succession of such expressions as it follows: 16(1 0.8 (1 1))-7(0 0 1 0)-3(1 1)

Now it works fine for what it does but I find it inelegant:
You can only have on set of parenthesis inside another, what would be really cool is something in which you could have an infinite number of sub-parenthesis such as in the [expr] object like this: 64(1 0 (12 13 0 (0 1 (0 2) 4)) 1), but I have no programming knowledge to do this. I've spent a lot of time thinking about this but couldn't find a solution. If any-one has some ideas as to how to do this, please shoot!