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.