date:20200628

Re: [PD] getting vanilla gui objects into standalone builds

2020-06-28 Thread Dan Wilcox



> On Jun 28, 2020, at 3:42 PM, Jakob Laue  wrote:
> 
> Hi!
> Alright, so I have looked a little bit into pdparty and mobmuplat. Seriously 
> these are cool projects!
> But I would like to have standalone apps, so it seems that I cannot use both 
> of them..
> Maybe I need to go for ofelia then or try native coding.

Most likely you will need to do a combination of native coding with libpd.

> But it is also interesting what you mentioned about purr-data. I have heard 
> of it a lot, but i dont know what it is.

It's a version of desktop Pd with the UI implemented in javascript using for a 
built-in web browser. The details are here: https://agraef.github.io/purr-data/ 


> You mentioned that purr-data is able to port the native guis to 
> non-tk-frameworks.

No.

> Does this mean e.g. porting to iOS?

No.

> I guess I need to take a look into purr-data as well:)

For regular patching on desktop computers, yes. For building projects and 
deploying on mobile platforms, no.

>  
> All the best, jakob
>  
>  
> Gesendet: Sonntag, 21. Juni 2020 um 20:15 Uhr
> Von: "Dan Wilcox" 
> An: "Jakob Laue" 
> Cc: "Pd-List" , "Christof Ressi" 
> , "enrike" 
> Betreff: Re: [PD] getting vanilla gui objects into standalone builds
> Howdy Jakob,
>  
> There is no "standalone GUI" for mobile. The UI widgets for PdDroidParty and 
> my own PdParty are custom re-implementations which intercept messages using 
> sends/receives. Both apps are open source, so you can reuse the widgets but 
> PdDroidParty's implementation is not feature complete, ie. no radio buttons, 
> etc. MobMuPlat, for instance, uses the Pd UI implementation form PdParty.
>  
> For mobile, it's often better to use the native sliders and buttons and send 
> the state changes to/from libpd. Either way, you will have to do native 
> platform coding & integration, unless you simply want to run patches, in 
> which case try using PdParty and/or PdDroidParty.
>  
> My long-term plan is to bring changes into libpd & the pd core so GUI 
> messaging could be abstracted to make porting the native UIs to non-Tk 
> frameworks easier. Purr-data has achieved this, for instance, so we know it's 
> possible.
>  
> On Jun 21, 2020, at 1:52 PM, Christof Ressi  > wrote:
>  
> Hi,
> 
> on desktop it's easy: just bundle Pd with your patch, add a simple starter 
> script and maybe use the KIOSK plugin to hide the console.
> 
> Mobile is tricky, because of the locked down nature of the platforms 
> (especially iOS). There are projects to run Pd patches on Android 
> (http://droidparty.net/ ) and iOS 
> (http://danomatika.com/code/pdparty ) 
> with some compatibility between the two 
> (http://danomatika.com/code/pdparty/guide#pddroid-party-compatibility 
> ). You 
> have to follow some conventions, though.
> 
> If you design your patch for PdParty and/or PdDroidParty and don't use mobile 
> specific features, it should automatically work in desktop Pd vanilla. I 
> think @Dan can tell you more about it.
> 
> Christof
> 
> On 21.06.2020 12:16, Jakob Laue wrote:
> Hey dear friends,
> i am currently building an instrument with many vanilla-native gui objects 
> (mainly buttons).
> I would like to build standalone versions of that patch, preferably for 
> linux, osx, ios and android.
> I know that building standalones is possible eg with ofxPof or ofelia. But as 
> far as i know, if i use ofxPof or ofelia, I will need to use "their" gui 
> objects, which means re-working my patch.
>  
> Do you know of a tool that allows building standalone versions from a pd 
> patch that will keep the original pd-vanilla-gui objects - or even better - a 
> tool that is able to "convert" pd-vanilla-gui objects into its own types of 
> gui objects, which look maybe a bit different from the pd-object, but fulfill 
> the same purpose?
>  
> :-)))
>  
> Best, jakob
>
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list 
> 
>  
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
>  


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-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:

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:

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] getting vanilla gui objects into standalone builds

2020-06-28 Thread hans w. koch

well, as a relative oldie, let me tell you this is wrong :-)
last commit to github 5 days ago: https://git.purrdata.net/jwilkes/purr-data
last relase: 26 days ago (14 committs since): 
https://github.com/agraef/purr-data/releases

or your world is aging fatser than mine…

hth
hans

> Am 28.06.2020 um 16:28 schrieb henry birdseye :
> 
> As a relative newbie to PD, let me suggest that PurrData is old, and 
> incomplete. Unless you have a very specific reason for using it, PD Vanilla 
> is the one to use. 
> 
> On 6/28/2020 9:42 AM, Jakob Laue wrote:
>> Hi!
>> Alright, so I have looked a little bit into pdparty and mobmuplat. Seriously 
>> these are cool projects!
>> But I would like to have standalone apps, so it seems that I cannot use both 
>> of them..
>> Maybe I need to go for ofelia then or try native coding.
>>  
>> But it is also interesting what you mentioned about purr-data. I have heard 
>> of it a lot, but i dont know what it is. You mentioned that purr-data is 
>> able to port the native guis to non-tk-frameworks. Does this mean e.g. 
>> porting to iOS? I guess I need to take a look into purr-data as well:)
>>  
>> All the best, jakob
>>  
>>  
>> Gesendet: Sonntag, 21. Juni 2020 um 20:15 Uhr
>> Von: "Dan Wilcox" 
>> An: "Jakob Laue" 
>> Cc: "Pd-List" , "Christof Ressi" 
>> , "enrike" 
>> Betreff: Re: [PD] getting vanilla gui objects into standalone builds
>> Howdy Jakob,
>>  
>> There is no "standalone GUI" for mobile. The UI widgets for PdDroidParty and 
>> my own PdParty are custom re-implementations which intercept messages using 
>> sends/receives. Both apps are open source, so you can reuse the widgets but 
>> PdDroidParty's implementation is not feature complete, ie. no radio buttons, 
>> etc. MobMuPlat, for instance, uses the Pd UI implementation form PdParty.
>>  
>> For mobile, it's often better to use the native sliders and buttons and send 
>> the state changes to/from libpd. Either way, you will have to do native 
>> platform coding & integration, unless you simply want to run patches, in 
>> which case try using PdParty and/or PdDroidParty.
>>  
>> My long-term plan is to bring changes into libpd & the pd core so GUI 
>> messaging could be abstracted to make porting the native UIs to non-Tk 
>> frameworks easier. Purr-data has achieved this, for instance, so we know 
>> it's possible.
>>  
>> On Jun 21, 2020, at 1:52 PM, Christof Ressi  wrote:
>>  
>> Hi,
>> 
>> on desktop it's easy: just bundle Pd with your patch, add a simple starter 
>> script and maybe use the KIOSK plugin to hide the console.
>> 
>> Mobile is tricky, because of the locked down nature of the platforms 
>> (especially iOS). There are projects to run Pd patches on Android 
>> (http://droidparty.net/) and iOS (http://danomatika.com/code/pdparty) with 
>> some compatibility between the two 
>> (http://danomatika.com/code/pdparty/guide#pddroid-party-compatibility). You 
>> have to follow some conventions, though.
>> 
>> If you design your patch for PdParty and/or PdDroidParty and don't use 
>> mobile specific features, it should automatically work in desktop Pd 
>> vanilla. I think @Dan can tell you more about it.
>> 
>> Christof
>> 
>> On 21.06.2020 12:16, Jakob Laue wrote:
>> Hey dear friends,
>> i am currently building an instrument with many vanilla-native gui objects 
>> (mainly buttons).
>> I would like to build standalone versions of that patch, preferably for 
>> linux, osx, ios and android.
>> I know that building standalones is possible eg with ofxPof or ofelia. But 
>> as far as i know, if i use ofxPof or ofelia, I will need to use "their" gui 
>> objects, which means re-working my patch.
>>  
>> Do you know of a tool that allows building standalone versions from a pd 
>> patch that will keep the original pd-vanilla-gui objects - or even better - 
>> a tool that is able to "convert" pd-vanilla-gui objects into its own types 
>> of gui objects, which look maybe a bit different from the pd-object, but 
>> fulfill the same purpose?
>>  
>> :-)))
>>  
>> Best, jakob
>>
>> ___
>> 
>> Pd-list@lists.iem.at
>>  mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>  
>> 
>> 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
> ___
> 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] getting vanilla gui objects into standalone builds

2020-06-28 Thread henry birdseye

As a relative newbie to PD, let me suggest that PurrData is old, and 
incomplete. Unless you have a very specific reason for using it, PD 
Vanilla is the one to use.


On 6/28/2020 9:42 AM, Jakob Laue wrote:

Hi!
Alright, so I have looked a little bit into pdparty and mobmuplat. 
Seriously these are cool projects!
But I would like to have standalone apps, so it seems that I cannot 
use both of them..

Maybe I need to go for ofelia then or try native coding.
But it is also interesting what you mentioned about purr-data. I have 
heard of it a lot, but i dont know what it is. You mentioned that 
purr-data is able to port the native guis to non-tk-frameworks. Does 
this mean e.g. porting to iOS? I guess I need to take a look into 
purr-data as well:)

All the best, jakob
*Gesendet:* Sonntag, 21. Juni 2020 um 20:15 Uhr
*Von:* "Dan Wilcox" 
*An:* "Jakob Laue" 
*Cc:* "Pd-List" , "Christof Ressi" 
, "enrike" 

*Betreff:* Re: [PD] getting vanilla gui objects into standalone builds
Howdy Jakob,
There is no "standalone GUI" for mobile. The UI widgets for 
PdDroidParty and my own PdParty are custom re-implementations which 
intercept messages using sends/receives. Both apps are open source, so 
you can reuse the widgets but PdDroidParty's implementation is not 
feature complete, ie. no radio buttons, etc. MobMuPlat, for instance, 
uses the Pd UI implementation form PdParty.
For mobile, it's often better to use the native sliders and buttons 
and send the state changes to/from libpd. Either way, you will have to 
do native platform coding & integration, unless you simply want to run 
patches, in which case try using PdParty and/or PdDroidParty.
My long-term plan is to bring changes into libpd & the pd core so GUI 
messaging could be abstracted to make porting the native UIs to non-Tk 
frameworks easier. Purr-data has achieved this, for instance, so we 
know it's possible.


On Jun 21, 2020, at 1:52 PM, Christof Ressi
mailto:i...@christofressi.com>> wrote:

Hi,

on desktop it's easy: just bundle Pd with your patch, add a simple
starter script and maybe use the KIOSK plugin to hide the console.

Mobile is tricky, because of the locked down nature of the
platforms (especially iOS). There are projects to run Pd patches
on Android (http://droidparty.net/) and iOS
(http://danomatika.com/code/pdparty) with some compatibility
between the two
(http://danomatika.com/code/pdparty/guide#pddroid-party-compatibility).
You have to follow some conventions, though.

If you design your patch for PdParty and/or PdDroidParty and don't
use mobile specific features, it should automatically work in
desktop Pd vanilla. I think @Dan can tell you more about it.

Christof

On 21.06.2020 12:16, Jakob Laue wrote:

Hey dear friends,
i am currently building an instrument with many vanilla-native
gui objects (mainly buttons).
I would like to build standalone versions of that patch,
preferably for linux, osx, ios and android.
I know that building standalones is possible eg with ofxPof or
ofelia. But as far as i know, if i use ofxPof or ofelia, I
will need to use "their" gui objects, which means re-working
my patch.
Do you know of a tool that allows building standalone versions
from a pd patch that will keep the original pd-vanilla-gui
objects - or even better - a tool that is able to "convert"
pd-vanilla-gui objects into its own types of gui objects,
which look maybe a bit different from the pd-object, but
fulfill the same purpose?
:-)))
Best, jakob

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


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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] getting vanilla gui objects into standalone builds

2020-06-28 Thread Jakob Laue

Hi!

Alright, so I have looked a little bit into pdparty and mobmuplat. Seriously these are cool projects!

But I would like to have standalone apps, so it seems that I cannot use both of them..

Maybe I need to go for ofelia then or try native coding.

But it is also interesting what you mentioned about purr-data. I have heard of it a lot, but i dont know what it is. You mentioned that purr-data is able to port the native guis to non-tk-frameworks. Does this mean e.g. porting to iOS? I guess I need to take a look into purr-data as well:)

All the best, jakob

Gesendet: Sonntag, 21. Juni 2020 um 20:15 Uhr
Von: "Dan Wilcox"
An: "Jakob Laue"
Cc: "Pd-List" , "Christof Ressi" , "enrike"
Betreff: Re: [PD] getting vanilla gui objects into standalone builds

Howdy Jakob,

There is no "standalone GUI" for mobile. The UI widgets for PdDroidParty and my own PdParty are custom re-implementations which intercept messages using sends/receives. Both apps are open source, so you can reuse the widgets but PdDroidParty's implementation is not feature complete, ie. no radio buttons, etc. MobMuPlat, for instance, uses the Pd UI implementation form PdParty.

For mobile, it's often better to use the native sliders and buttons and send the state changes to/from libpd. Either way, you will have to do native platform coding & integration, unless you simply want to run patches, in which case try using PdParty and/or PdDroidParty.

My long-term plan is to bring changes into libpd & the pd core so GUI messaging could be abstracted to make porting the native UIs to non-Tk frameworks easier. Purr-data has achieved this, for instance, so we know it's possible.

On Jun 21, 2020, at 1:52 PM, Christof Ressi wrote:

Hi,

on desktop it's easy: just bundle Pd with your patch, add a simple starter script and maybe use the KIOSK plugin to hide the console.

Mobile is tricky, because of the locked down nature of the platforms (especially iOS). There are projects to run Pd patches on Android (http://droidparty.net/) and iOS (http://danomatika.com/code/pdparty) with some compatibility between the two (http://danomatika.com/code/pdparty/guide#pddroid-party-compatibility). You have to follow some conventions, though.

If you design your patch for PdParty and/or PdDroidParty and don't use mobile specific features, it should automatically work in desktop Pd vanilla. I think @Dan can tell you more about it.

Christof

On 21.06.2020 12:16, Jakob Laue wrote:

Hey dear friends,

i am currently building an instrument with many vanilla-native gui objects (mainly buttons).

I would like to build standalone versions of that patch, preferably for linux, osx, ios and android.

I know that building standalones is possible eg with ofxPof or ofelia. But as far as i know, if i use ofxPof or ofelia, I will need to use "their" gui objects, which means re-working my patch.

Do you know of a tool that allows building standalone versions from a pd patch that will keep the original pd-vanilla-gui objects - or even better - a tool that is able to "convert" pd-vanilla-gui objects into its own types of gui objects, which look maybe a bit different from the pd-object, but fulfill the same purpose?

:-)))

Best, jakob

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

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-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] [PD-announce] AoO (audio over OSC) v2.0-pre2

2020-06-28 Thread Christof Ressi


Hi, can you open an issue on Gitlab? https://git.iem.at/cm/aoo/-/issues

Christof

On 28.06.2020 06:56, Lucas Cordiviola wrote:


Hi Christof,

I'm testing this patch[1] which works Ok inside my lan but when I try 
with others outside I get:


~~
aoo_client: couldn't establish UDP connection to groupa|win81; timed 
out after 5

 seconds
~~

I use "vrr.iem.at" or my own [aoo_server].

What am I missing?



[1] (main.pd) https://nc.nubegris.com.ar/index.php/s/Sw8y2Br7cy7nAxP

Mensaje telepatico asistido por maquinas.
On 6/22/2020 10:20 AM, Christof Ressi wrote:


Dear list,

here's a new pre-release for the AoO multichannel audio streaming 
library. In the last two months, the library has been seen many 
improvements and has been used successfully in our Virtual Rehearsal 
Room project (see vrr.iem.at ).


Binaries for all common platforms (Windows, macOS, Linux, ARM boards) 
are available on Deken (search for "aoo"). The source code can be 
found here: https://git.iem.at/cm/aoo


See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd, 
aoo_server.pd) for usage instructions.


If you want to stream between different home networks (without port 
forwarding), you can use [aoo_client] and connect to our public AoO 
server at the IEM (hostname: vrr.iem.at, port: 7077). You can easily 
set up your own AoO server by running a Pd patch containing 
[aoo_server ] on your web server.


---

Selected features:

# create audio networks of any topology with arbitrary ad-hoc connections
# [aoo_send~] / [aoo_receive~] take a port number and ID, so multiple 
objects (within a single Pd instance) can operate on the same port. 
Additionally, you can have multiple objects across different Pd 
instances (using different port numbers).

# [aoo_send~] can stream to several destinations simultaneously;
# [aoo_receive~] can receive several AoO streams simultaneously, 
summing the signals
# AoO is connectionless: streams can start/stop at any time, enabling a 
"message-based audio" approach.
# AoO sinks can "invite" sources, i.e. ask them to send audio. The 
source may follow the invitation or decline it.

# AoO sinks and sources can operate at different blocksizes and samplerates
# the streaming format can be set independently for each source; 
currently only PCM (uncompressed) and Opus (compressed) are 
implemented, but this can be easily extended with the AoO codec 
plugin API.

# audio encoding/decoding is multithreaded
# adjustable resending mechanism for dropped packets
# adjustable jitter buffer size.
# [aoo_server] / [aoo_client] implement the UDP hole punching technique 
to establish peer2peer connections between different home networks.
# AoO is actually a C++ library with a C interface, so it can be used 
in apps or embedded devices (like the ESP32). An implementation for 
Supercollider is already planned.


---

For questions, bug reports or feature requests, please open an issue 
at https://git.iem.at/cm/aoo/-/issues. We're very happy about any 
kind of feedback!


Christof


___
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

Re: [PD] getting vanilla gui objects into standalone builds

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

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

Re: [PD] getting vanilla gui objects into standalone builds

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

Re: [PD] getting vanilla gui objects into standalone builds

Re: [PD] getting vanilla gui objects into standalone builds

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

Re: [PD] [PD-announce] AoO (audio over OSC) v2.0-pre2

9 matches

Site Navigation

Mail list logo

Footer information