Re: [PD] OSC problem

[Christof Ressi]

I have made a little program in Unity to send over OSC (port 7000)
If you use UDP (which you normally would), then a [netreceive -u -b 
7000] in Pd should give you the *raw* OSC message. "-u" stands for UDP 
and "-b" stands for binary. Alternatively, you can also use 
[iemnet/udpreceive 7000].


Then you have to convert the raw bytes to a Pd message, e.g. with 
[unpackOSC] (from "mrpeach" resp. "osc") or Pd vanilla's [oscparse].


Anyway, netreceive print to the console: slipdec: maximum packet 
length is 65536.
This error message definitely comes from the [slipdec] object.Totally 
off topic, but these OSC addresses look weird. Why not use /trigger/0/0 
and /trigger/34/1 ?


Christof

On 08.02.2021 22:02, Csaba Láng wrote:

Dear list,

I have made a little program in Unity to send over OSC (port 7000) 60 
times per second if a trigger was touched or not (1 and 0 respectively)


However, any of my tries if it was over localnetwork or via IP to port 
7000 nothing comes to Pd.
Tried udp, tcp and netreceive but cannot catch any of the signals 
which looks like this

/trigger0/0 or /trigger34/1

Anyway, netreceive print to the console: slipdec: maximum packet 
length is 65536.


What could go wrong?
When I use Arena or Artnet the OSC is running with all the info I 
need, but Pd is muted totally.


Best,

Popesz


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] OSC problem

[Csaba Láng]

Dear list,

I have made a little program in Unity to send over OSC (port 7000) 60 times
per second if a trigger was touched or not (1 and 0 respectively)

However, any of my tries if it was over localnetwork or via IP to port 7000
nothing comes to Pd.
Tried udp, tcp and netreceive but cannot catch any of the signals which
looks like this
/trigger0/0 or /trigger34/1

Anyway, netreceive print to the console: slipdec: maximum packet length is
65536.

What could go wrong?
When I use Arena or Artnet the OSC is running with all the info I need, but
Pd is muted totally.

Best,

Popesz
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] FFTease 3.0 now available for Pd

[Alexandre Torres Porres]

YAY!!!

Awesome, FFTease is an incredible library and a must have, thanks for it!
:)


Em seg., 8 de fev. de 2021 às 12:33, Eric Lyon 
escreveu:

> Greetings,
>
> I'm pleased to announce that FFTease 3.0 is now available for Pd. Based on
> a project started in 1999 by Christopher Penrose and myself, FFTease is a
> set of externals designed to make the exploration of FFT-based spectral
> processing as easy as possible. The package may be accessed through deken
> (search for "fftease") or directly downloaded from the Github distribution
> . Github would be the best place
> to send bug reports or any other feedback.
>
> Thanks to @porres, @umlaeute, and @Lucarda for invaluable assistance and
> contributions throughout this process.
>
> Eric
> ___
> Pd-announce mailing list
> pd-annou...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-announce
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] FFTease 3.0 now available for Pd

[Eric Lyon]

Greetings,

I'm pleased to announce that FFTease 3.0 is now available for Pd. Based on
a project started in 1999 by Christopher Penrose and myself, FFTease is a
set of externals designed to make the exploration of FFT-based spectral
processing as easy as possible. The package may be accessed through deken
(search for "fftease") or directly downloaded from the Github distribution
. Github would be the best place to
send bug reports or any other feedback.

Thanks to @porres, @umlaeute, and @Lucarda for invaluable assistance and
contributions throughout this process.

Eric
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [textfile] vs [text define]

[hans w. koch]

+1 in heaping praise on [text] and its comrades: albeit a bit slow with growing 
size, it allows for loads of data manipulation in a very flexible way.

hans

> Am 08.02.2021 um 09:57 schrieb Lorenzo Sutton :
> 
> On 06/02/21 23:28, Christof Ressi wrote:
>> They all operate on binbufs internally, so there shouldn't be a significant 
>> performance difference.
> 
> For certain scenarios I find the -k flag for [text define]  useful as it 
> allows you to save the contents (keep it) with the patch. This (having some 
> data embedded in the patch vs. in an external text file), might be desirable 
> or not, but it's defintely a nice to have the option and AFIK [textfile] 
> deosn't have this kind of option.
> 
> Personally I also like it that you can have different objects which clearly 
> do different things like 'define', 'get', 'insert', 'size', 'tolist' instead 
> of having to look at messages attached to them... Maybe because I've been 
> playing with pseudo-random MIDI generation lately, but this is really a very 
> subjective preference :-)
> 
> Lorenzo.
> 
>> On 06.02.2021 23:18, Alexandre Torres Porres wrote:
>>> I guess the advantage is if it runs faster or not, right?
>>> 
>>> Em sáb., 6 de fev. de 2021 às 18:03, Christof Ressi >> > escreveu:
>>> 
>>>> are there any concrete advantages?
>>>What's the advantage of having two different objects for the same
>>>job?
>>>If you like [textfile] for its simple interface, keep using it.
>>>I'm just
>>>saying that it's more or less obsolete.
>>> 
>>>On 06.02.2021 16:38, João Pais wrote:
>>>> It is surely overall more powerful. But when using it just for
>>>> read/get whole lines/save, are there any concrete advantages?
>>>>
>>>>
>>>>> [text define] is basically a more powerful and flexible
>>>replacement
>>>>> for [textfile] and [qlist]. I would only use [textfile] if you
>>>prefer
>>>>> the simpler interface or need the [add2( method. Personally, I
>>>only
>>>>> use [text define].
>>>>>
>>>>> Christof
>>>>>
>>>>> On 06.02.2021 14:28, João Pais wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> for simple read/get/save operation, are there are advantages on
>>>>>> using [text define] instead of [textfile]?
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> jmmmp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Pd-list@lists.iem.at  mailing list
>>>>>> UNSUBSCRIBE and account-management ->
>>>>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Pd-list@lists.iem.at  mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>> 
>>> 
>>> 
>>>___
>>>Pd-list@lists.iem.at  mailing list
>>>UNSUBSCRIBE and account-management ->
>>>https://lists.puredata.info/listinfo/pd-list
>>>
>>> 
>>> 
>>> ___
>>> Pd-list@lists.iem.at  mailing list
>>> UNSUBSCRIBE and account-management 
>>> ->https://lists.puredata.info/listinfo/pd-list
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [textfile] vs [text define]

[Lorenzo Sutton]

On 06/02/21 23:28, Christof Ressi wrote:
They all operate on binbufs internally, so there shouldn't be a 
significant performance difference.


For certain scenarios I find the -k flag for [text define]  useful as it 
allows you to save the contents (keep it) with the patch. This (having 
some data embedded in the patch vs. in an external text file), might be 
desirable or not, but it's defintely a nice to have the option and AFIK 
[textfile] deosn't have this kind of option.


Personally I also like it that you can have different objects which 
clearly do different things like 'define', 'get', 'insert', 'size', 
'tolist' instead of having to look at messages attached to them... Maybe 
because I've been playing with pseudo-random MIDI generation lately, but 
this is really a very subjective preference :-)


Lorenzo.



On 06.02.2021 23:18, Alexandre Torres Porres wrote:

I guess the advantage is if it runs faster or not, right?

Em sáb., 6 de fev. de 2021 às 18:03, Christof Ressi 
mailto:i...@christofressi.com>> escreveu:


> are there any concrete advantages?
What's the advantage of having two different objects for the same
job?
If you like [textfile] for its simple interface, keep using it.
I'm just
saying that it's more or less obsolete.

On 06.02.2021 16:38, João Pais wrote:
> It is surely overall more powerful. But when using it just for
> read/get whole lines/save, are there any concrete advantages?
>
>
>> [text define] is basically a more powerful and flexible
replacement
>> for [textfile] and [qlist]. I would only use [textfile] if you
prefer
>> the simpler interface or need the [add2( method. Personally, I
only
>> use [text define].
>>
>> Christof
>>
>> On 06.02.2021 14:28, João Pais wrote:
>>> Hi list,
>>>
>>> for simple read/get/save operation, are there are advantages on
>>> using [text define] instead of [textfile]?
>>>
>>>
>>> Best,
>>>
>>> jmmmp
>>>
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at  mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list

>>
>
>
>
>
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list