subject:"\[PD\] one abstraction, different delay lines\?"

Re: [PD] one abstraction, different delay lines?

2020-07-15 Thread Jakob

Hey Christoph,
Thank you for these nice explanations!
Haha thats funny, i only know debouncing from electronics, where debouncing 
hardware switches is an important thing. But indeed, it is the same technique 
here:-)

I would definitely share the opinion that the system should not produce clicks 
when all effects are busy working. So my first step will be to figure out how 
many button sets and hence effects my system is allowed to have. I guess, that 
saving cpu will be a nice to have feature for later.
Best Jakob

> Am 11.07.2020 um 20:27 schrieb Christof Ressi :
> 
>> How would I do this? Is it possible to somehow check the volume that is 
>> going out to the outlets of a clone?
> Yes, but you need to use [send~]/[receive~] resp. [throw~]/[catch~], so can 
> analyze a specific output and not the sum of all outputs. A simple way is to 
> check the output of [env~]. The blocksize can be very short (e.g. 64 samples) 
> and you don't need overlap. Of course, the silence/signal detection has to 
> happen outside the actual subpatch, because DSP must be running.
> There is one problem, though: if the input signal has pauses, the processed 
> signal might have pauses too, so must not switch off immediately, but only 
> after a certain amount of silent blocks in a row. This technique of avoiding 
> rapid state changes is called "debouncing". You can schedule the switch off 
> with [delay] and send a [stop( message if a block is not silent. The delay 
> time should correspond to the max. number of samples until the plugin output 
> becomes silent (= "tail size").
> 
> Actually, VST plugins often employ this technique to save CPU. For many VST2 
> and VST3 plugins, the host can ask the plugin for its "tail size", so it 
> knows when it can stop processing. VST3 plugins also have a "silence flag" 
> for each channel which can be set by the host, so the plugin itself can 
> suspend processing if appropriate.
> 
> On the other hand, some people argue that the system must be able to handle 
> the max. number of effects anyway, and if you run all effects all the time 
> and the CPU can manage it, you won't get any surprises. Of course, the big 
> disadvantage is that the system uses more power than necessary most of the 
> time.
> 
> Christof
> 
>> On 11.07.2020 18:55, Jakob Laue wrote:
>> Hi!
>> So, I was thinking about Dan's advice to turn the dsp on and off with 
>> [switch]. I will definitely need this feature for saving CPU.
>> Currently I am wondering which is the proper condition on that I decide to 
>> [switch] a clone off.
>> Let me explain with an example:
>> Say I have 10 button matrices, therefore I have 10 clones of my 
>> delay-effect. Each clone the delay-effect for one specific button matrix. 
>> When the user is playing a melody on the first button matrix and then 
>> switches to the second matrix, I am not allowed to [switch] off the delay 
>> effect on the first matrix, because even if the first matrix might not be 
>> triggering new midi notes anymore, the delay effect might be set to feedback 
>> = 100, an thus is still playing music.
>>  
>> So my first idea was to switch off the delay effect, when dryWet and 
>> feedback are set to zero. But then I would also have to check wether or not 
>> there is music coming in on the inlets off the delay effect...And what if I 
>> am not using a delay but a reverb effect. Then I would have to check 
>> different sliders...a little bit confusing i would say.
>>  
>> So then I had another idea: Couldn't I simply check (periodically) whether 
>> or not a delay-effect-clone is still sending audio to its outlets? I think 
>> that this would be a good general approach that could be applied to other 
>> effects, as well. How would I do this? Is it possible to somehow check the 
>> volume that is going out to the outlets of a clone?
>>  
>> Best, Jakob
>>  
>>  
>> Gesendet: Mittwoch, 01. Juli 2020 um 12:30 Uhr
>> Von: "Dan Wilcox" 
>> An: "Jakob Laue" 
>> Cc: "Pd-List" 
>> Betreff: Re: [PD] one abstraction, different delay lines?
>> (My mail program mangled this message for some reason, so I copy/pasted the 
>> quote below. I hope it's the correct one to respond to...)
>>  
>> Right now I have the master audio stream (= the audio of all matrices) going 
>> into the clone object, so it sounds like i have several delay effects with 
>> different settings on the master channel. It sounds nice, but it is not what 
>> I want right now:)
>>  
>> Jakob, the next step would be to add a [switch~] object to each of the 
>> instances inside

Re: [PD] one abstraction, different delay lines?

2020-07-11 Thread Christof Ressi

How would I do this? Is it possible to somehow check the volume that 
is going out to the outlets of a clone?
Yes, but you need to use [send~]/[receive~] resp. [throw~]/[catch~], so 
can analyze a specific output and not the sum of all outputs. A simple 
way is to check the output of [env~]. The blocksize can be very short 
(e.g. 64 samples) and you don't need overlap. Of course, the 
silence/signal detection has to happen outside the actual subpatch, 
because DSP must be running.


There is one problem, though: if the input signal has pauses, the 
processed signal might have pauses too, so must not switch off 
immediately, but only after a certain amount of silent blocks in a row. 
This technique of avoiding rapid state changes is called "debouncing". 
You can schedule the switch off with [delay] and send a [stop( message 
if a block is not silent. The delay time should correspond to the max. 
number of samples until the plugin output becomes silent (= "tail size").


Actually, VST plugins often employ this technique to save CPU. For many 
VST2 and VST3 plugins, the host can ask the plugin for its "tail size", 
so it knows when it can stop processing. VST3 plugins also have a 
"silence flag" for each channel which can be set by the host, so the 
plugin itself can suspend processing if appropriate.


On the other hand, some people argue that the system must be able to 
handle the max. number of effects anyway, and if you run all effects all 
the time and the CPU can manage it, you won't get any surprises. Of 
course, the big disadvantage is that the system uses more power than 
necessary most of the time.


Christof

On 11.07.2020 18:55, Jakob Laue wrote:

Hi!
So, I was thinking about Dan's advice to turn the dsp on and off with 
[switch]. I will definitely need this feature for saving CPU.
Currently I am wondering which is the proper condition on that I 
decide to [switch] a clone off.

Let me explain with an example:
Say I have 10 button matrices, therefore I have 10 clones of my 
delay-effect. Each clone the delay-effect for one specific button 
matrix. When the user is playing a melody on the first button matrix 
and then switches to the second matrix, I am not allowed to [switch] 
off the delay effect on the first matrix, because even if the first 
matrix might not be triggering new midi notes anymore, the delay 
effect might be set to feedback = 100, an thus is still playing music.
So my first idea was to switch off the delay effect, when dryWet and 
feedback are set to zero. But then I would also have to check wether 
or not there is music coming in on the inlets off the delay 
effect...And what if I am not using a delay but a reverb effect. Then 
I would have to check different sliders...a little bit confusing i 
would say.
So then I had another idea: Couldn't I simply check (periodically) 
whether or not a delay-effect-clone is still sending audio to its 
outlets? I think that this would be a good general approach that could 
be applied to other effects, as well. How would I do this? Is it 
possible to somehow check the volume that is going out to the outlets 
of a clone?

Best, Jakob
*Gesendet:* Mittwoch, 01. Juli 2020 um 12:30 Uhr
*Von:* "Dan Wilcox" 
*An:* "Jakob Laue" 
*Cc:* "Pd-List" 
*Betreff:* Re: [PD] one abstraction, different delay lines?
(My mail program mangled this message for some reason, so I 
copy/pasted the quote below. I hope it's the correct one to respond to...)


Right now I have the master audio stream (= the audio of all matrices) 
going into the clone object, so it sounds like i have several delay effects 
with different settings on the master channel. It sounds nice, but it is not 
what I want right now:)

Jakob, the next step would be to add a [switch~] object to each of the 
instances inside the clone object, then enable/disable based which one 
you want to use. That could work as dsp will not be performed on those 
which are switched off, saving CPU.
A simple solution is for each instance to accept an "on" message with 
a float (1 or 0) to enable/disable. Then to enable as ingle one, send 
a [all on 0< message followed by the single one to enable, [1 on 1<.


On Jul 1, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at
<mailto:pd-list-requ...@lists.iem.at> wrote:
Message: 1
Date: Tue, 30 Jun 2020 13:31:57 +0200
From: Jakob Laue mailto:jakkesprin...@web.de>>
To: Christof Ressi mailto:i...@christofressi.com>>
    Cc: Pd-List mailto:pd-list@lists.iem.at>>
Subject: Re: [PD] one abstraction, different delay lines?
Message-ID:



Content-Type: text/plain; charset="utf-8"

An HTML attachment was scrubbed...
URL:

<http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html>


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com &l

Re: [PD] one abstraction, different delay lines?

2020-07-11 Thread Jakob Laue

Hi!

So, I was thinking about Dan's advice to turn the dsp on and off with [switch]. I will definitely need this feature for saving CPU.

Currently I am wondering which is the proper condition on that I decide to [switch] a clone off.

Let me explain with an example:

Say I have 10 button matrices, therefore I have 10 clones of my delay-effect. Each clone the delay-effect for one specific button matrix. When the user is playing a melody on the first button matrix and then switches to the second matrix, I am not allowed to [switch] off the delay effect on the first matrix, because even if the first matrix might not be triggering new midi notes anymore, the delay effect might be set to feedback = 100, an thus is still playing music.

 

So my first idea was to switch off the delay effect, when dryWet and feedback are set to zero. But then I would also have to check wether or not there is music coming in on the inlets off the delay effect...And what if I am not using a delay but a reverb effect. Then I would have to check different sliders...a little bit confusing i would say.

 

So then I had another idea: Couldn't I simply check (periodically) whether or not a delay-effect-clone is still sending audio to its outlets? I think that this would be a good general approach that could be applied to other effects, as well. How would I do this? Is it possible to somehow check the volume that is going out to the outlets of a clone?

 

Best, Jakob

 
 

Gesendet: Mittwoch, 01. Juli 2020 um 12:30 Uhr
Von: "Dan Wilcox" 
An: "Jakob Laue" 
Cc: "Pd-List" 
Betreff: Re: [PD] one abstraction, different delay lines?



(My mail program mangled this message for some reason, so I copy/pasted the quote below. I hope it's the correct one to respond to...)
 

Right now I have the master audio stream (= the audio of all matrices) going into the clone object, so it sounds like i have several delay effects with different settings on the master channel. It sounds nice, but it is not what I want right now:)

 

Jakob, the next step would be to add a [switch~] object to each of the instances inside the clone object, then enable/disable based which one you want to use. That could work as dsp will not be performed on those which are switched off, saving CPU.

 

A simple solution is for each instance to accept an "on" message with a float (1 or 0) to enable/disable. Then to enable as ingle one, send a [all on 0< message followed by the single one to enable, [1 on 1<.

 


On Jul 1, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
 

Message: 1
Date: Tue, 30 Jun 2020 13:31:57 +0200
From: Jakob Laue <jakkesprin...@web.de>
To: Christof Ressi <i...@christofressi.com>
Cc: Pd-List <pd-list@lists.iem.at>
Subject: Re: [PD] one abstraction, different delay lines?
Message-ID:


Content-Type: text/plain; charset="utf-8"

An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html>


 




Dan Wilcox

@danomatika

danomatika.com

robotcowboy.com

 










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

Re: [PD] one abstraction, different delay lines?

2020-07-04 Thread Jakob

Hi Dan,
Thanks for that advice! I am using [switch~]es inside the [clone]d „instrument 
collection“ that is sitting in front of the cloned delay effect. But you are 
right, adding this functionality to the delay effect instances will surely safe 
some cpu, too

Best, Jakob

> Am 01.07.2020 um 12:30 schrieb Dan Wilcox :
> 
> (My mail program mangled this message for some reason, so I copy/pasted the 
> quote below. I hope it's the correct one to respond to...)
> 
>> Right now I have the master audio stream (= the audio of all matrices) going 
>> into the clone object, so it sounds like i have several delay effects with 
>> different settings on the master channel. It sounds nice, but it is not what 
>> I want right now:)
> 
> Jakob, the next step would be to add a [switch~] object to each of the 
> instances inside the clone object, then enable/disable based which one you 
> want to use. That could work as dsp will not be performed on those which are 
> switched off, saving CPU.
> 
> A simple solution is for each instance to accept an "on" message with a float 
> (1 or 0) to enable/disable. Then to enable as ingle one, send a [all on 0< 
> message followed by the single one to enable, [1 on 1<.
> 
>> On Jul 1, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>> 
>> Message: 1
>> Date: Tue, 30 Jun 2020 13:31:57 +0200
>> From: Jakob Laue 
>> To: Christof Ressi 
>> Cc: Pd-List 
>> Subject: Re: [PD] one abstraction, different delay lines?
>> Message-ID:
>>  
>> 
>>  
>> Content-Type: text/plain; charset="utf-8"
>> 
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html>
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] one abstraction, different delay lines?

2020-07-01 Thread Dan Wilcox

(My mail program mangled this message for some reason, so I copy/pasted the 
quote below. I hope it's the correct one to respond to...)

> Right now I have the master audio stream (= the audio of all matrices) going 
> into the clone object, so it sounds like i have several delay effects with 
> different settings on the master channel. It sounds nice, but it is not what 
> I want right now:)

Jakob, the next step would be to add a [switch~] object to each of the 
instances inside the clone object, then enable/disable based which one you want 
to use. That could work as dsp will not be performed on those which are 
switched off, saving CPU.

A simple solution is for each instance to accept an "on" message with a float 
(1 or 0) to enable/disable. Then to enable as ingle one, send a [all on 0< 
message followed by the single one to enable, [1 on 1<.

> On Jul 1, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Tue, 30 Jun 2020 13:31:57 +0200
> From: Jakob Laue mailto:jakkesprin...@web.de>>
> To: Christof Ressi mailto:i...@christofressi.com>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] one abstraction, different delay lines?
> Message-ID:
>   
> 
>   
> Content-Type: text/plain; charset="utf-8"
> 
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html
>  
> <http://lists.puredata.info/pipermail/pd-list/attachments/20200630/9648c0c4/attachment-0001.html>>

Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>

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

Re: [PD] one abstraction, different delay lines?

2020-06-30 Thread Jakob Laue

great, i will try to get that done:-) thanks!

Gesendet: Dienstag, 30. Juni 2020 um 13:21 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

Is there a way to do this?
Just use [s~]/[r~] resp. [throw~]/[catch~] inside the cloned abstraction with a symbol containing the instance number ($1), e.g. [catch~ /foo/in/$1]. This is kind of the standard way to implement multichannel stuff in Pd at the moment.

Christof

On 30.06.2020 13:07, Jakob Laue wrote:

Hi!

Okay, so I tried out the clone object and I understood how to apply different parameters of "feedback", "dryWet" and "timing" to the different clones of my delay-abstraction. Now I have another question:-)

In the helpfile for [clone] it says that inputs on signal level will be copied to each clone of my delay-abstraction. For now, this is not what I want because I want the audio of my first matrix to be going to the first clone of my delay-abstraction, then the audio of my second matrix to be going to the second clone of my second abstraction and so on...

Is there a way to do this? I heard about logical operations on signal level, but I haven't spent time with this yet.

Right now I have the master audio stream (= the audio of all matrices) going into the clone object, so it sounds like i have several delay effects with different settings on the master channel. It sounds nice, but it is not what I want right now:)

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 17:24 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

have a look at the [clone] object ;-)

On 28.06.2020 17:06, Jakob Laue wrote:

One that I could do is build a delay-abstraction that receives the number of different matrices on[loadbang] and then dynamically patches inside itself the various needed [delwrite~]'s, [vd]'s and so on.

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 15:33 Uhr
Von: "Jakob Laue"
An: "Christof Ressi"
Cc: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

Hello again!
Yep, maybe I should explain what I want to do :-P
I am building a sequencer instrument that mainly consists of a matrix of push buttons.
When you press a button in a column and the sequencer arrives there, then a certain midi note is played through an instrument and into [dac~].

The user can go through several matrices, allowing him to play e.g. a melody on matrix 1 and another melody on matrix 2.
Now my next steps are:
- implementing the possibility for an instrument change, so that the user is able to specify an instrument he wants his midi note to go to for his different matrices
- implementing the possibility for a delay effect per matrix: Say the user is on matrix 1 and plays a melody there. Now he chooses to activate a delay effect for this matrix. For this I could take the delay-effect-abstraction that I mentioned.
The user plays a little bit with the "feedback", "dry/wet" and "delay timing" settings. The user hears the delay effect.

Now we are approaching what I want to achieve: The user is happy with his melody and his delay-settings on matrix 1. Now the user changes to the second matrix because he wants to play another melody on top. Internally, he does this by incrementing a counter to value 2. The second melody should NOT be affected by the delay settings that the user applied for the melody on matrix 1. This means, that each matrix needs to have its own delay effect or its own delay-effect-settings. What I could certainly do, is to copy and paste my delay-effect-abstraction to have two independent delay-effects for each matrix/each melody. But I would like to avoid to copy-and-paste because the number of matrices should be easily changeable. I want to keep the patch as generic as possible. At the moment I have a number for specifying the number of matrices. This number is [loadbanged] and the patch does the rest on startup. I would like to keep this. But for this, my delay abstraction has to be able
- to listen for a matrix-change (receiving the corresponding counter value)
- to save the settings for each matrix and show them when a matrix change is noticed
- to write into different delay lines for having the audio effect affect only the audio of a certain matrix.

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

Gesendet: Samstag, 27. Juni 2020 um 21:20 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?
so that it will be able to write into/create different delay lines "on the fly"?It's currently not possible to dynamically changing the source delay line ("write into") for objects like [delread~] or [vd~], bu

Re: [PD] one abstraction, different delay lines?

2020-06-30 Thread Christof Ressi


Is there a way to do this?
Just use [s~]/[r~] resp. [throw~]/[catch~] inside the cloned abstraction 
with a symbol containing the instance number ($1), e.g. [catch~ 
/foo/in/$1]. This is kind of the standard way to implement multichannel 
stuff in Pd at the moment.


Christof

On 30.06.2020 13:07, Jakob Laue wrote:

Hi!
Okay, so I tried out the clone object and I understood how to apply 
different parameters of "feedback", "dryWet" and "timing" to the 
different clones of my delay-abstraction. Now I have another question:-)
In the helpfile for [clone] it says that inputs on signal level will 
be copied to each clone of my delay-abstraction. For now, this is not 
what I want because I want the audio of my first matrix to be going to 
the first clone of my delay-abstraction, then the audio of my second 
matrix to be going to the second clone of my second abstraction and so 
on...
Is there a way to do this? I heard about logical operations on signal 
level, but I haven't spent time with this yet.
Right now I have the master audio stream (= the audio of all matrices) 
going into the clone object, so it sounds like i have several delay 
effects with different settings on the master channel. It sounds nice, 
but it is not what I want right now:)


All the best, Jakob
*Gesendet:* Sonntag, 28. Juni 2020 um 17:24 Uhr
*Von:* "Christof Ressi" 
*An:* "Pd-List" 
*Betreff:* Re: [PD] one abstraction, different delay lines?

have a look at the [clone] object ;-)

On 28.06.2020 17:06, Jakob Laue wrote:

One that I could do is build a delay-abstraction that receives the
number of different matrices on[loadbang] and then dynamically
patches inside itself the various needed [delwrite~]'s, [vd]'s and
so on.
All the best, Jakob
*Gesendet:* Sonntag, 28. Juni 2020 um 15:33 Uhr
*Von:* "Jakob Laue" 
*An:* "Christof Ressi" 
    *Cc:* "Pd-List" 
*Betreff:* Re: [PD] one abstraction, different delay lines?
Hello again!
Yep, maybe I should explain what I want to do :-P
I am building a sequencer instrument that mainly consists of a
matrix of push buttons.
When you press a button in a column and the sequencer arrives
there, then a certain midi note is played through an instrument
and into [dac~].

The user can go through several matrices, allowing him to play
e.g. a melody on matrix 1 and another melody on matrix 2.
Now my next steps are:
- implementing the possibility for an instrument change, so that
the user is able to specify an instrument he wants his midi note
to go to for his different matrices
- implementing the possibility for a delay effect per matrix: Say
the user is on matrix 1 and plays a melody there. Now he chooses
to activate a delay effect for this matrix. For this I could take
the delay-effect-abstraction that I mentioned.
The user plays a little bit with the "feedback", "dry/wet" and
"delay timing" settings. The user hears the delay effect.

Now we are approaching what I want to achieve: The user is happy
with his melody and his delay-settings on matrix 1. Now the user
changes to the second matrix because he wants to play another
melody on top. Internally, he does this by incrementing a counter
to value 2. The second melody should NOT be affected by the delay
settings that the user applied for the melody on matrix 1. This
means, that each matrix needs to have its own delay effect or its
own delay-effect-settings. What I could certainly do, is to copy
and paste my delay-effect-abstraction to have two independent
delay-effects for each matrix/each melody. But I would like to
avoid to copy-and-paste because the number of matrices should be
easily changeable. I want to keep the patch as generic as
possible. At the moment I have a number for specifying the number
of matrices. This number is [loadbanged] and the patch does the
rest on startup. I would like to keep this. But for this, my delay
abstraction has to be able
- to listen for a matrix-change (receiving the corresponding
counter value)
- to save the settings for each matrix and show them when a matrix
change is noticed
- to write into different delay lines for having the audio effect
affect only the audio of a certain matrix.

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob




Gesendet: Samstag, 27. Juni 2020 um 21:20 Uhr
Von: "Christof Ressi" 
An: "Pd-List" 
Betreff: Re: [PD] one abstraction, different delay lines?

so that it will be able to write into/create different delay lines
"on the fly"?It's currently not possible to dynamically changing
the source delay line ("write into") for object

Re: [PD] one abstraction, different delay lines?

2020-06-30 Thread Jakob Laue

Hi!

Is there a way to do this? I heard about logical operations on signal level, but I haven't spent time with this yet.

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 17:24 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

have a look at the [clone] object ;-)

On 28.06.2020 17:06, Jakob Laue wrote:

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 15:33 Uhr
Von: "Jakob Laue"
An: "Christof Ressi"
Cc: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

On 27.06.2020 19:06, Jakob Laue wrote:

Re: [PD] one abstraction, different delay lines?

2020-06-28 Thread Jakob Laue

Ah, i heard of that, I will take a look:)

"clone" sounds promising:)

Gesendet: Sonntag, 28. Juni 2020 um 17:24 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

have a look at the [clone] object ;-)

On 28.06.2020 17:06, Jakob Laue wrote:

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 15:33 Uhr
Von: "Jakob Laue"
An: "Christof Ressi"
Cc: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

On 27.06.2020 19:06, Jakob Laue wrote:

Dear pders:)
Recently I have built my first abstraction for a delay-effect.
Now I have a question. Is it possible to extend this abstraction in a way,
so that it will be able to write into/create different delay lines "on the fly"?
Thanks, Jakob
___pd-l...@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[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[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] one abstraction, different delay lines?

2020-06-28 Thread Christof Ressi

have a look at the [clone] object ;-)

On 28.06.2020 17:06, Jakob Laue wrote:
One that I could do is build a delay-abstraction that receives the
number of different matrices on[loadbang] and then dynamically patches
inside itself the various needed [delwrite~]'s, [vd]'s and so on.

All the best, Jakob
*Gesendet:* Sonntag, 28. Juni 2020 um 15:33 Uhr
*Von:* "Jakob Laue"
*An:* "Christof Ressi"
*Cc:* "Pd-List"
*Betreff:* Re: [PD] one abstraction, different delay lines?
Hello again!
Yep, maybe I should explain what I want to do :-P
I am building a sequencer instrument that mainly consists of a matrix
of push buttons.
When you press a button in a column and the sequencer arrives there,
then a certain midi note is played through an instrument and into [dac~].

The user can go through several matrices, allowing him to play e.g. a
melody on matrix 1 and another melody on matrix 2.

Now my next steps are:
- implementing the possibility for an instrument change, so that the
user is able to specify an instrument he wants his midi note to go to
for his different matrices
- implementing the possibility for a delay effect per matrix: Say the
user is on matrix 1 and plays a melody there. Now he chooses to
activate a delay effect for this matrix. For this I could take the
delay-effect-abstraction that I mentioned.
The user plays a little bit with the "feedback", "dry/wet" and "delay
timing" settings. The user hears the delay effect.

Now we are approaching what I want to achieve: The user is happy with
his melody and his delay-settings on matrix 1. Now the user changes to
the second matrix because he wants to play another melody on top.
Internally, he does this by incrementing a counter to value 2. The
second melody should NOT be affected by the delay settings that the
user applied for the melody on matrix 1. This means, that each matrix
needs to have its own delay effect or its own delay-effect-settings.
What I could certainly do, is to copy and paste my
delay-effect-abstraction to have two independent delay-effects for
each matrix/each melody. But I would like to avoid to copy-and-paste
because the number of matrices should be easily changeable. I want to
keep the patch as generic as possible. At the moment I have a number
for specifying the number of matrices. This number is [loadbanged] and
the patch does the rest on startup. I would like to keep this. But for
this, my delay abstraction has to be able
- to listen for a matrix-change (receiving the corresponding counter
value)
- to save the settings for each matrix and show them when a matrix
change is noticed
- to write into different delay lines for having the audio effect
affect only the audio of a certain matrix.

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

Gesendet: Samstag, 27. Juni 2020 um 21:20 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

so that it will be able to write into/create different delay lines "on
the fly"?It's currently not possible to dynamically changing the
source delay line ("write into") for objects like [delread~] or [vd~],
but it would be good feature request! I'm not sure why you would want
to dynamically "create" a delay line, though.

Christof

On 27.06.2020 19:06, Jakob Laue wrote:

Thanks, Jakob
___pd-l...@lists.iem.at[mailto:Pd-list@lists.iem.at]
mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list[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[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] one abstraction, different delay lines?

2020-06-28 Thread Jakob Laue

All the best, Jakob

Gesendet: Sonntag, 28. Juni 2020 um 15:33 Uhr
Von: "Jakob Laue"
An: "Christof Ressi"
Cc: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

On 27.06.2020 19:06, Jakob Laue wrote:

___
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] one abstraction, different delay lines?

2020-06-28 Thread Jakob Laue

Hello again!
Yep, maybe I should explain what I want to do :-P
I am building a sequencer instrument that mainly consists of a matrix of push
buttons.
When you press a button in a column and the sequencer arrives there, then a
certain midi note is played through an instrument and into [dac~].

The user can go through several matrices, allowing him to play e.g. a melody on
matrix 1 and another melody on matrix 2.
Now my next steps are:
- implementing the possibility for an instrument change, so that the user is
able to specify an instrument he wants his midi note to go to for his different
matrices
- implementing the possibility for a delay effect per matrix: Say the user is
on matrix 1 and plays a melody there. Now he chooses to activate a delay effect
for this matrix. For this I could take the delay-effect-abstraction that I
mentioned.
The user plays a little bit with the "feedback", "dry/wet" and "delay timing"
settings. The user hears the delay effect.

Now we are approaching what I want to achieve: The user is happy with his
melody and his delay-settings on matrix 1. Now the user changes to the second
matrix because he wants to play another melody on top. Internally, he does this
by incrementing a counter to value 2. The second melody should NOT be affected
by the delay settings that the user applied for the melody on matrix 1. This
means, that each matrix needs to have its own delay effect or its own
delay-effect-settings. What I could certainly do, is to copy and paste my
delay-effect-abstraction to have two independent delay-effects for each
matrix/each melody. But I would like to avoid to copy-and-paste because the
number of matrices should be easily changeable. I want to keep the patch as
generic as possible. At the moment I have a number for specifying the number of
matrices. This number is [loadbanged] and the patch does the rest on startup. I
would like to keep this. But for this, my delay abstraction has to be able
- to listen for a matrix-change (receiving the corresponding counter value)
- to save the settings for each matrix and show them when a matrix change is
noticed
- to write into different delay lines for having the audio effect affect only
the audio of a certain matrix.

I hope that it is more clear now:-)

At the moment, I have absolutely no idea how i could achieve this:-(

All the best, Jakob

Gesendet: Samstag, 27. Juni 2020 um 21:20 Uhr
Von: "Christof Ressi"
An: "Pd-List"
Betreff: Re: [PD] one abstraction, different delay lines?
so that it will be able to write into/create different delay lines "on the
fly"?It's currently not possible to dynamically changing the source delay line
("write into") for objects like [delread~] or [vd~], but it would be good
feature request! I'm not sure why you would want to dynamically "create" a
delay line, though.
Christof

On 27.06.2020 19:06, Jakob Laue wrote:

Dear pders:)
Recently I have built my first abstraction for a delay-effect.
Now I have a question. Is it possible to extend this abstraction in a way,
so that it will be able to write into/create different delay lines "on the fly"?
Thanks, Jakob
___pd-l...@lists.iem.at[mailto:Pd-list@lists.iem.at]
mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list[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[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] one abstraction, different delay lines?

2020-06-27 Thread Christof Ressi

so that it will be able to write into/create different delay lines "on 
the fly"?
It's currently not possible to dynamically changing the source delay 
line ("write into") for objects like [delread~] or [vd~], but it would 
be good feature request! I'm not sure why you would want to dynamically 
"create" a delay line, though.


Christof

On 27.06.2020 19:06, Jakob Laue wrote:

Dear pders:)
Recently I have built my first abstraction for a delay-effect.
Now I have a question. Is it possible to extend this abstraction in a 
way,
so that it will be able to write into/create different delay lines "on 
the fly"?

Thanks, Jakob

___
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] one abstraction, different delay lines?

2020-06-27 Thread IOhannes m zmölnig

On 2020-06-27 19:06, Jakob Laue wrote:
> Dear pders:)
> Recently I have built my first abstraction for a delay-effect.
> Now I have a question. Is it possible to extend this abstraction in a way,
> so that it will be able to write into/create different delay lines "on the 
> fly"?

short answer: yes.

longer answer: your question is very generic so the short answer is very
generic as well.
i don't know your "first abstraction". i have no idea what it does
(apart from being a "delay-effect").
i don't even know whether it can be "extended" in *any* way.
you might want to provide more information about both what you have and
what you actually want to achieve ("creating different delay lines" is
probably not your goal, but what you think is the best way to achieve
your goal).

gfamrd
IOhannes

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

[PD] one abstraction, different delay lines?

2020-06-27 Thread Jakob Laue

Dear pders:)

Recently I have built my first abstraction for a delay-effect.

Now I have a question. Is it possible to extend this abstraction in a way, 

so that it will be able to write into/create different delay lines "on the fly"?

 

Thanks, Jakob



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

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

Re: [PD] one abstraction, different delay lines?

[PD] one abstraction, different delay lines?

15 matches

Site Navigation

Mail list logo

Footer information