Pigini's Forum Page

@Zynewave wrote:

Next up is resizing all selected notes when using the mouse to resize one of the selected events. One question though:

Say you have two note events selected, one longer than the other. What should happen if you click the longer note and drag the size shorter than the other selected note. Should the shorter note be deleted, or should it be set to zero duration producing only a short click when played back?

I think it should shorten until a certain minimum is reached. If quantization was on, setting the minimum to the quantization value sounds fine, if not the minimum could possibly be defined somewhere where it could be changed, if needed. Does not need a prominent place in the preferences, the default could be something practical for most (1/128 note?).
Setting it to zero duration or deleting the note sounds not very desirable to me.

Another thing about changing durations for multiple selected notes:
I remember in muzys after resizing a box appeared, where one could choose how the duration change should be done.
absolute: sets durations of all selected notes to the value of the changed note.
relative: subtract the same amount from every note, like from the changed note.
percent: that’s the thing most hosts have, it scales every selected note proportionally.

Maybe in podium a similar choice of behaviours could be included?

edited:spelling

@pavouk100 wrote:

@Pigini wrote:

whatelse could be done with layers?
– layer clips could be “transparent” (adding to the events underneath) or “opaque” (replacing events underneath it).
– “clipped” draggable edges, so the sequence within it could be bigger, the clip range working like a selection window. (it might only show a part of whats on the layer)
– could be merged

But IMHO all this can be achieved by putting separate events into child tracks of the track with VSTi, everything needed is already present. Sorry for being in that ‘do not add overlapping or duplicate features’ crowd again 😉

😈 Arrgh, Restistance is futile! 😈 (always wanted to do that..)

🙂 No prob, I first thought it could all be done with tracks myself.

…but then I realized, they are just not as good a solution for some tasks, for others they are not suited at all. (There are 2 posts about possible tasks for layers, and there are surely many more poss., I did not think of)

I don’t have the time right now to elaborate on that in detail. But one thing is, creating a huge amount of tracks in track view and in the mixer, when I just don’t need or want them, really is an unnecessary bloating and crowding with tracks.
(I know, I could do many things to stuff them away, making it look slimmer. But the point is, for the tasks, I’m thinking of, you never want or need them in the first place, with all the mixer channels etc.)

I think including layers would be a major feature and mean quite a big amount of work for Frits, but IMHO they would fit into Podiums basic concept, adding a third dimension to it. I see it like another basic element, to open up lots of ways to use it and to combine it with other elements in podium.

I’m not “urging” the whole layer stuff into the discussion, but as a possible thing, that could be added to the piano roll, I felt it belonged into “our bag of ideas”.

Edit: In all the references regarding possible uses of layers, I was exclusively thinking of advanced fiddling with the midi data in the piano roll. Maybe that was not completely clear.

Just had a quick look using the beta with the usb-sticked podium, that I can use on my work computer.
The button panel really does the trick for me.
Inputing and editing notes is an absolute joy now, and you found a great place to put the buttons.
Can’t wait having a real session with it on my music computer.
Thank you!!! 🙂

@H-man wrote:

With all respect to Pigini’s idea, I don’t really like the idea of going form 2.09 to 2.35 to 2.416 (?) etc. I get what it means, it just feels strange.

MuLab went from 2.02 to 2.5 mainly for adding rewire support, a major feature, quite some bit of work I suppose. Podium modestly only went from 2.01 to 2.02 for that.
I mean the versioning should reflect the amount of work and changes better. Wasn’t that the idea of version schemes, once?
You could easily see, if there were many features added or mainly bugfixes.

I would not bother so much about a completely new version numbering.
I think the current one is absolutely ok. It’s incremental, ongoing, in a way versioning was originally meant do be.

What I never understood was, how some ppl expected major changes, going from 1.99 to 2.0. You are giving us all the inbetweens, instead of secretly working for half a year on a bigger stepping, so logically going from 1.99 to 2.0 had to be an incremental step.

If you compare 1.0 to 2.0, you do have a major difference in features, much more than you would usually see in other apps, that inflate the whole versioning scheme just for PR. (Just look at energy-xt, selling a 2.5 version for showing off, based on an August 2008 beta, while a 2.07beta was released in november 2008.)

But what you rightfully could and should do (IMHO) is, let every small feature change do a count on the version clock.
Then you could have 2.09 being followed by 2.30, having each single improvement in the piano roll do a step on the version meter.
Or count a 0.01 step for a bugfix, 0.1 for an added feature or change.
Right now, the version number does not show the amount of improvements.

The numbering scheme itself does not need to be reinvented, only weighted.

Alternatively, if you absolutely want the year in it, call it “Podium 2009” and carry on with the ususal versioning in the about box.

@H-man wrote:

BTW, the layers idea I quite like. For someone who has been trying to finish a skin for a plugin for six or so weeks, I would have to say that it vastly changes the creative paradigm.

It might be a harder one to code, but it seems the best choice for integrating some creative fiddling into podium in a way that fits podiums workflow best.

whatelse could be done with layers?
– layer clips could be “transparent” (adding to the events underneath) or “opaque” (replacing events underneath it).
– “clipped” draggable edges, so the sequence within it could be bigger, the clip range working like a selection window. (it might only show a part of whats on the layer)
– could be merged

That objections from the “already one way to do it”-crowd remind me a bit of the discussions, when some hosts (like massiva) started to offer a simple and quick way to assign your vst’s directly to the tracks, instead of doing it on the mixer screen.

There are enough examples for more than one way of achieving the same results. I think a host should work a bit like a graphics app for music, giving you all kinds of tools for the creation/manipulation of your data in all the many ways any combination of utilizing those tools allows.

The more tools and the more ways to combine them, the more ways to do things, where everybody might find his favourite technique.

Anyway, what Mike suggested was another way of linking functional elements along with a few examples how it could be used.
For many things it might be even quicker than the other way.
And I don’t think connecting some already existing functions in a new way, could result in bloat.

It’s never a bad thing for a host, having some unique features.

What sounds better in a review?
“Podium, besides being able of handling all the basic production needs, in addition offers many rather unique and original ways to achieve outstanding results very quickly.”
OR
“Podium is an affordable bread and butter host, which offers a solid selection of the most important features and working techniques, which you might know from cubase already.”

I don’t think, Podium is that host described in the last sentence, but only because Frits wasn’t content with the one way of doing things before.