Zynewave@Podianer wrote:
😳 My registration was in summer 2005… 🙂 It was different then, right? 🙄
Yes, I think I enabled it later on. You can see the image if you log out and click the register link.
ZynewaveWhy don’t you consider a different registration form, such as most other forums have nowadays. The ones where one has to enter certain numbers shown on a graphic.
The registration form already uses that feature, but most bots have become so smart that they can decode the picture. There are a lot of different “mods” available for the phpbb forum software that can help limit the automatic bot registrations. I’ll probably try one of those soon. See this link:
ZynewaveHowever why must we choose between the two?
Is this because of the way Podium is set up, wired or developed?
It’s not a problem specific to Podium. How would you prevent the need for selecting a track, either when you copy/paste from track to track or time to time?
If I must choose then I would 100% go with acousmods suggestions as the necessity to select a track first, to ensure copying and pasting works properly on the same track, is nothing compared to the current problem of pasting to different tracks especially in very busy projects.
There’s a chance that some will find this a change to the worse. That’s why I would like to hear user opinions. To reiterate: If I change it to the way acousmod describes, then you have to select the very first track that has any selected events on it, to paste events to another time location on the same tracks.
ZynewaveI activated SpamAssassin last night after I got the 1000 spam emails. I’m still getting the emails, but at least now I can sort them from the regular emails and delete them in a single action.
ZynewaveFirst you said this
“If you want to paste events to another time position on the same tracks, then you don’t need to worry with selecting the track”.
then this….
“But when you want to copy/paste to a different time position you then have to select the first track that has any selected events. Otherwise the events will not be pasted on the same tracks they were copied from”.
The “then this” quote is the scenario that will happen if I change the paste mechanism so that pasting from track to track is easier. It’s either one or the other type of paste (track to track, or time to time) that will suffer. That’s why I asked which type of paste you most often perform.
ZynewaveI’m using SpamAssassin, which is installed by my host provider on the server. This adds a spam notification in the subject (e.g. “**SPAM**”) to all suspected spam emails so that I can filter them in my email client. If the problem persists I can also activate automatic deletion of the spam emails at the server, so that I won’t receive them at all.
ZynewaveWhich of these two types of copy/paste are you most frequently using: Pasting to different tracks, or pasting to another time position on the same track?
How copy/paste currently works: When you copy events on tracks to the clipboard, they are stored with a relative track offset from the current track. When you paste events they are placed on tracks that are offset from the current track.
If you want to paste events to another time position on the same tracks, then you don’t need to worry with selecting the track. But if you want to paste to different tracks, then you need to select the first track, copy, select the target track, and paste.
The logical way would be to :
– click on a clip (or a selection) to select it (them)
– copy
– click on a track
– paste : the clip is pasted on this track at the cursor position.
If there was more than one clip selected, they are pasted in the relative position of the first one, if they were on several tracks they are pasted in the following tracks and new tracks are automatically created if they don’t exist.
If this approach is used, then the track selection problem is the other way around. Copying to different tracks will be simpler. But when you want to copy/paste to a different time position you then have to select the first track that has any selected events. Otherwise the events will not be pasted on the same tracks they were copied from.
ZynewaveI’ll try to add track event/note event muting for the 1.74 release.
ZynewaveIt should be easy to add a mute feature for individual sequence or sound events. There could be a “Mute Events” command in the edit menu and the event context menu. The sequence event would be drawn in the greyed out mode similar to events on a muted track, and possible an “M” icon next to the name to indicate the event is muted.
Muting individual note events is another matter I think. Are there anyone (other than Max) that would find this useful?
ZynewaveCurrently you can only mute a track and not individual events on the track. Could you describe the situation where you would want to mute an individual clip on a track?
ZynewaveHi pj,
I have never tried the XP Media Center Edition, and I have not had reports concerning this either. Have you tried Podium yet on the Media Center? Any problems?
ZynewaveSo when we move the event, the fades move together with it, no ?
Yes, of course. What I meant was that the fade duration was stored using the time resolution of the arrangement, instead of a sample offset. So if you had a fade-in duration of e.g. a 1/16th note, and changed the arrangement tempo, the resulting fade-in time in samples would change as well. I am now changing this so that the fade durations are stored as sample offsets.
ZynewaveI think even thinking of not trying something similar depending on the results with Beat is a bit strange to me. What other idea or avenues do you have in mind that can reach that many of your target market for free?
Of course I intend to contact other magazines to try similar arrangements, but the Beat cooperation will give me a sense of what to expect from such a promotion. Depending on the sales generated, perhaps creating a feature-limited version is better than giving away a full version. Or setting up upgrade rebates for the magazine readers, etc.
Zynewave
I’ve now got the fades working. After some tests I’m having doubts on how best to store the fade in/out durations. Currently they are locked to the arrangement timeline. Thus if you change the arrangement tempo, or time-stretch a sound event (not yet implemented), the fade in/out positions will move in relation to the actual waveform. Would it be better to have the fade in/out positions lock to the actual waveform data?
Zynewave@kingtubby wrote:
Are you prepared for the inevitable flood of new-user questions in the forum Frits? 😉
I’m certainly curious to see how big the response will be. Maybe I’ll have to set up a “Deutsch” support forum 😉
The outcome of this whole experience/experiment will determine whether I should try something similar with other magazines.