Carlo

I would like to ask for two features to be implemented in Max 5.0, if possible.

First, could it be possible to put a keyboard shortcut for fast cleaning max window (instead of ctrl-x or "clear" in the popup menu)?

Second, why don't you consider the idea to put a grid of reference numbers on the spectrogram window, to allow to see better what's going on in the frequency domain? May I ask for a mouse driven pointer that tells both frequency and amplitude when clicked, also?

Hi,
I would like to ask for two features to be implemented in Max 5.0, if possible.
First, could it be possible to put a keyboard shortcut for fast cleaning max window (instead of ctrl-x or "clear" in the popup menu)?
Second, why don't you consider the idea to put a grid of reference numbers on the spectrogram window, to allow to see better what's going on in the frequency domain? May I ask for a mouse driven pointer that tells both frequency and amplitude when clicked, also?
Thank you very much.

max-5-feature-requests

Can I ask why there is a limitation to the number of elements in a 

max list? is it not possible to change that?

On 18 Sep 2007, at 19:33, Carlo Laurenzi wrote:

> I would like to ask for two features to be implemented in Max 5.0, 

> First, could it be possible to put a keyboard shortcut for fast 

> cleaning max window (instead of ctrl-x or "clear" in the popup menu)?

> Second, why don't you consider the idea to put a grid of reference 

> numbers on the spectrogram window, to allow to see better what's 

> going on in the frequency domain? May I ask for a mouse driven 

> pointer that tells both frequency and amplitude when clicked, also?

Can I ask why there is a limitation to the number of elements in a  
max list? is it not possible to change that?

> Hi,
> I would like to ask for two features to be implemented in Max 5.0,  
> if possible.
> First, could it be possible to put a keyboard shortcut for fast  
> cleaning max window (instead of ctrl-x or "clear" in the popup menu)?
> Second, why don't you consider the idea to put a grid of reference  
> numbers on the spectrogram window, to allow to see better what's  
> going on in the frequency domain? May I ask for a mouse driven  
> pointer that tells both frequency and amplitude when clicked, also?
> Thank you very much.
>
> Carlo Laurenzi


> Can I ask why there is a limitation to the number of elements in a

> max list? is it not possible to change that?

Why: Memory and efficiency, but related to pretty old machines

(Mac+ with a 68000 processor at 8 MHz and 1MB of RAM...).

The list itself isn't limited, the objects are. mxj listoperators can 

peiman khosravi schrieb:
> Can I ask why there is a limitation to the number of elements in a
> max list? is it not possible to change that?

Why: Memory and efficiency, but related to pretty old machines
(Mac+ with a 68000 processor at 8 MHz and 1MB of RAM...).
The list itself isn't limited, the objects are. mxj listoperators can 
deal with list lengths of 4095...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


those are some great ideas... the number cursor for debugging?? great, no need for those endless "test" number boxes.

I'd also like a settable speed for the Autostep in the Trace, even just Slow - Med - Fast.

The "split window" feature would be cool, like when doing Dreamweaver or another html editor and you can see both the design and the code. It would really help understand how the Max code works.

Since we're on the subject of feature requests for debugging, I wish Max had some basic profiling tools built in. Here's what I'm picturing:

1. Click "start profile; (with the understanding that this is going to introduce some overhead)

4. View the profiling data, which might include:

- Number of messages received to each object in the patch (maybe keep track of each inlet separately?)

- Number of time spent processing in each object

Ideally the data would be sorted by number of messages/processing time, so it would be easy to pinpoint the bottlenecks.

Keeping track of number of messages received isn't as useful for MSP objects, so maybe for MSP objects there could be another metric like amount of time active (i.e. not muted, etc).

1. Click "start profile; (with the understanding that this is going to introduce some overhead)
2. Run a patch for a while
3. Click "stop profile"
4. View the profiling data, which might include:
   - Number of messages received to each object in the patch (maybe keep track of each inlet separately?)
   - Number of time spent processing in each object

I'd like resizeable buffers (without the loss of buffer content), and a streaming recorder. Actually it would be great if the buffer could do everything possible in supercollider !

A multibuffer would also be nice,- you should just give it a name and how many buffers to create,- and they could all be concatenated with an index number... a writeall message could save all the files to disk,- and a readfolder would read all files in a folder and hand out ID's...

A collset (like the matrixst) would also be nice !

I'd would be nice to have a sort of preset, that could save and recall everything,- the contents of buffers, colls, matrix, and all other settings... Like a memory dump of sort. Not that i'm not satisfied with pattr system,- but it would be a nice option for saving those works in progress making great sound, which is often the case here...

I remember David C, telling that we can do a lot of new stuff with debugging and the max window,- so looking forward to see what they have come up with...

Clicking error messages in the max object, should surface the object,- maybe even make it blink... That would be very great !

> The "split window" feature would be cool, like when doing Dreamweaver

> or another html editor and you can see both the design and the code.

> It would really help understand how the Max code works.

I never would understand how a patch works by looking at its code, I 

always understand it by looking at the patch. I'd never use it I guess. 

The text representation is for machines, but is hackable like code in an 

hex editor. Its not ment to be understood, because you need to count 

You can always open the patch as text in another window, I'd rather let 

the cycling folks concentrate on important stuff...

Seejay James schrieb:
> The "split window" feature would be cool, like when doing Dreamweaver
> or another html editor and you can see both the design and the code.
> It would really help understand how the Max code works.

I never would understand how a patch works by looking at its code, I 
always understand it by looking at the patch. I'd never use it I guess. 
The text representation is for machines, but is hackable like code in an 
hex editor. Its not ment to be understood, because you need to count 
lines and things like that...
You can always open the patch as text in another window, I'd rather let 
the cycling folks concentrate on important stuff...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

How about "paste-replace but keep existing arguments".

paste-replacing those with a modified version won't nuke the arguments...

Yes you can crop buffers with waveform, but i'm talking about the ability to make a buffer longer without loss of content,- then we could record for a long time and stop recording, with perfect bufferlength... The opposite of crop would also be nice, delete what is marked by the waveform.

The buffer in supercollider is much more free,- the object can do all of what i'm asking... It can be resized in realtime , without loss of content... Both to bigger & smaller size, - surely you lose content when making buffers smaller...

I know you can do multibuffer with scripting (check CNMAT objects), but i think it would be more stable if it was an object,- not that important though... btw I don't find it an easy thing to do ;)

recording in loopmode is not streaming,- what tapin~ does is,- maybe just let tapin~ point to a buffer ?

Year,- i don't think we'll get the memory dump (or what to name it), but it would be nice though... I use a little to much perfecting the preset system in my patches i guess.

What i'd like is just a system that can store everything at once,- "what i'm doing right now sounds nice,- i wanna use it in performance..." press dump as.. or what ever, and all buffers, colls, matrix, etc gets written to disk...

I know it's asking a lot,- and i already have this system,- but it would be nice if it worked on the standard objects...

What i'd like is just a system that can store everything at once,- "what i'm doing right now sounds nice,- i wanna use it in performance..." press dump as.. or what ever, and all buffers, colls, matrix, etc gets written to disk...
I know it's asking a lot,- and i already have this system,- but it would be nice if it worked on the standard objects...


Quote: johnpitcairn wrote on Wed, 26 September 2007 01:39

----------------------------------------------------

> How about "paste-replace but keep existing arguments".

> paste-replacing those with a modified version won't nuke the arguments...

Quote: johnpitcairn wrote on Wed, 26 September 2007 01:39
----------------------------------------------------
> How about "paste-replace but keep existing arguments".
>
> So if you have:
>
> [p test1 2 3 4]
> [p test2 5 6 7]
>
> paste-replacing those with a modified version won't nuke the arguments...
>
----------------------------------------------------

Ok heres one..and this is knowing full and well that whats in (and what isnt in) Max 5 is probably locked... BUT

it would be really cool is there was an option to enable a pattr-style address in the title bar.

What I mean by this is that when you are in a sub-patch, rather than the title of the subpatch being something like 

it could say root::grandparent::parent::Subpatch

I often find myself navigating to subpatches via send/receive links and dont know where i am in the patcher hierarchy. It would also be a nice complement addressing problems that I frequently run into in the pattr system.

Ok heres one..and this is knowing full and well that whats in (and what isnt in) Max 5 is probably locked... BUT 

it would be really cool is there was an option to enable a pattr-style address in the title bar. 

What I mean by this is that when you are in a sub-patch, rather than the title of the subpatch being something like 
[Subpatch] 

I often find myself navigating to subpatches via send/receive links and dont know where i am in the patcher hierarchy.  It would also be a nice complement addressing problems that I frequently run into in the pattr system.


We're back in the future: try alt-click on the title of your sub-sub- 

sub-patch window and see (on OS X at least)...

On Oct 5, 2007, at 1:23 AM, Nick Inhofe wrote:

> Ok heres one..and this is knowing full and well that whats in (and 

> what isnt in) Max 5 is probably lock BUT

> it would be really cool is there was an option to enable a pattr- 

> What I mean by this is that when you are in a sub-patch, rather 

> than the title of the subpatch being something like

> it could say root::grandparent::parent::Subpatch

> I often find myself navigating to subpatches via send/receive links 

> and dont know where i am in the patcher hierarchy. It would also 

> be a nice complement addressing problems that I frequently run into 

We're back in the future: try alt-click on the title of your sub-sub- 
sub-patch window and see (on OS X at least)...

>
> Ok heres one..and this is knowing full and well that whats in (and  
> what isnt in) Max 5 is probably lock BUT
>
> it would be really cool is there was an option to enable a pattr- 
> style address in the title bar.
>
> What I mean by this is that when you are in a sub-patch, rather  
> than the title of the subpatch being something like
> [Subpatch]
>
> it could say root::grandparent::parent::Subpatch
>
> I often find myself navigating to subpatches via send/receive links  
> and dont know where i am in the patcher hierarchy.  It would also  
> be a nice complement addressing problems that I frequently run into  
> in the pattr system.


> What is your route~ external/abstraction ? I can't find it on 

> maxobjects. I guess it works like [route signal] -> [t signal], doesn't 

jln schrieb:
> What is your route~ external/abstraction ? I can't find it on 
> maxobjects. I guess it works like [route signal] -> [t signal], doesn't 
> it ?

Max 5 feature requests..