qtractor-devel — Qtractor development discussion

Re: [Qtractor-devel] Issues with snapping /moving notes

[Ralf M. <ral...@al...>]

Hi Frank :)

at the moment I'm going on with a worse song. I won't start a new song 
until some issues are solved ;). In the background of my audio session 
I'm running Thunderbird, to be able to note each issue immediately.

While I received your mail, I wanted to note this:

I'm editing a clip from 2.01.000 to 6.01.000. The editors display shows 
the bars from 2.01.000 to 6.01.000+. If I delete a note or notes or if I 
undo an inserted note or notes, the editor view jumps and shows the 
beats from 5.02.000 to 9.01.000+. I need to scroll the view back to 
2.01.000+, if I want continue editing. It's no big deal for short clips, 
but for long clips it's no fun.

> Sooner or later the notes' onset time should be off a little, as in "1.04.002"
> or "1.03.955".
>   

I've got the same problem after copying notes.

> When multi-selecting some notes and dragging them around, after
> the mouse release event, the notes get unselected

It's the same here.

> One more sidenote: If I single-click a note (select it), I can use the cursor
> keys (left, right, up, down) to move the event. However, in doing this the
> snapping also fails

I'm not using this function, but I tried it now and it's the same here.

> Is there some hidden "humanize" feature somewhere? :-)
>   

No ;), it's a very evil bug. I'm thinking to join the Starship Troopers.

Btw. I'm still annoyed because of the problem with the loop/punch in/out 
markers. I don't like it, that they change their position when I select 
clips. There's no select mode banning this behaviour.

In addition to Qtractor's show-stoppers I have to handle my own 
foolishness. My worse song is based on an imported MIDI track I edited 
by using TuxGuitar. I made a mistake when writing the score, so starting 
with x.01.000 it's x.01.000, but x.02.000, x.03.000 and x.04.000 are at 
x.02.320, x.03.640 and x.01.000 etc. :D. Handling this in addition with 
handling a mix of normal and triplet notes and different signatures, 
plus the bugs for Qtractor is a disaster. I'm not sure if I really wrote 
a bad score by using TuxGuitar or if this is based on an export/ import 
bug, but I guess for this the blame is on me.

Cheers,
Ralf

[Qtractor-devel] Issues with snapping /moving notes

[Frank N. <bea...@we...>]

Hi,

I noticed the following today:
- Start qtractor (currently using 0.4.4)
- Create a new MIDI track, create a MIDI clip in it
- Set the Snap/beat parameter to "Beat"
- Edit the new clip, activate View->Events
- Switch the note time display to "BBT"
- Create some random notes - these should all align with their start time to
  something like "1.01.000", "1.03.000" etc.
- Create a lasso around these notes, and drag them around (move them forward or
  backward in time).

Sooner or later the notes' onset time should be off a little, as in "1.04.002"
or "1.03.955".
Expected behaviour: The onset times should stay exactly on the "x.y.000" position.
Is this some kind of rounding error?

On a sidenote: When multi-selecting some notes and dragging them around, after
the mouse release event, the notes get unselected - why? I might want to drag
them around a little more, so I'd appreciate if the previously made selection
remains active.

One more sidenote: If I single-click a note (select it), I can use the cursor
keys (left, right, up, down) to move the event. However, in doing this the
snapping also fails (with snap settings like in the above case), e.g. when moving
a perfectly "x.y.000" aligned note to the left or right, it will be placed "off"
a little as well, as in "x.y.004".
Is there some hidden "humanize" feature somewhere? :-)

Greetings,
Frank

Re: [Qtractor-devel] [ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild!

[Ralf M. <ral...@al...>]

Rui Nuno Capela wrote:
> select one whole clip by just clicking on it.
> am i missing something?
>   

Sometimes it's impossible to select a clip. As soon as you touch the 
clip, you don't have the cursor any more, but the resize tool, so you 
can resize the clip, but you can't mark it.

> well, the edit cursors (blue vertical marker lines) behavior in qtractor
> is something that is probably unique :) it should be noted that it just
> follows my own usability. it never tried to emulate any other daw,
> whatsoever :)
>
> loop and punch in/out ranges are always set from the current edit head and
> tail positions (the blue line markers) by pressing Transport/Loop or Punch
> In/out menu items or toolbar buttons. once set it won't change unless you
> toggle/set it again to newer edit marker positions.
>
> the edit-head and -tail markers (left and right blue marker lines resp.)
> can be moved freely, either on the main track view canvas or in the top
> time ruler and they often do follow the current clip selection range.
>
> current loop range is shown by green line markers. current punch-in/out
> markers are pink (magenta, light red). they are mutually exclusive. you
> cannot set loop when punching-in/out and vice versa.
>   

The problem is, that they don't stay in their positions when selecting 
clips, resp. to avoid this you need to chose between different select 
modes. Another issue is, that there's no way to store and restore markers.

> that sounds like custom location markers. besides tempo/time-signature
> changes, location markers are still missing implementation, long overdue,
> buried deep in the creepy TODO-pile :)

Yes, having a set of markers would be good, but in this case I'm only 
thinking about the view.

Ralf

Re: [Qtractor-devel] [ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild!

[Rui N. C. <rn...@rn...>]

On Sun, 17 Jan 2010 20:35:30 +0100, Ralf Mardorf wrote:
> Rui Nuno Capela wrote:
> 
>>> There are still some issues annoying when working with clips on tracks
>>> using "The Frisky Demivierge".
>>>
>>> - Some relative large clips are anyhow to small to select them by the
>>> mouse cursor, a zoom in is needed.
>>>
>>
>> large clips too small? rephrase that sentence, please
>>   
> 
> Small clips that are wider than the mouse cursor (so they are relative 
> wide) are hard to select by the mouse cursor, sometimes it's impossible 
> without zooming in.
> 

select one whole clip by just clicking on it. that works the same on all
select modes (clip, range or rect). also, if you want to toggle-select all
clips in the track, click on the left-most column (ie. colored track
number)

am i missing something?


>>> - The behaviour of the loop/ punch markers, when selecting by
rectangle,
>>> resp. that there's the need to change between clip and rectangle mode
to
>>> avoid an unwanted behaviour.
>>>
>>> - Setting up the loop/ punch markers sometimes can't be done just by
>>> left and right mouse button.
>>>     
>>
>> have you any other idea in mind?
>>   
> 
> Yesno ;), e.g. only Ctrl + mouse enables changing the markers or clicks 
> in the track area don't change the markers. IIRC Cubase and Muse are 
> fine for my needs, but I don't remember how it's solved for those apps.
> 

well, the edit cursors (blue vertical marker lines) behavior in qtractor
is something that is probably unique :) it should be noted that it just
follows my own usability. it never tried to emulate any other daw,
whatsoever :)

loop and punch in/out ranges are always set from the current edit head and
tail positions (the blue line markers) by pressing Transport/Loop or Punch
In/out menu items or toolbar buttons. once set it won't change unless you
toggle/set it again to newer edit marker positions.

the edit-head and -tail markers (left and right blue marker lines resp.)
can be moved freely, either on the main track view canvas or in the top
time ruler and they often do follow the current clip selection range.

current loop range is shown by green line markers. current punch-in/out
markers are pink (magenta, light red). they are mutually exclusive. you
cannot set loop when punching-in/out and vice versa.


>>> A nice feature would be,
>>>
>>> [long and confusing text on brohen English]
>>>     
>>
>> i really don't know what you're after, ... but,
>>
>> there can be only one tempo, time-signature map, on whole session
>> time-line.
>>
>> am i waaay too wrong thinking you did imply the possibility of
different
>> tempo/time-sigs on each and/or every track?
>>
> 
> No. What I would like to have is a coloured background for the area that

> represent the room (canvas) for the tracks, were the clips are arranged.

> At the moment it has the windows background colour, border colour or 
> what ever colour from the used theme. It would help if the background 
> over the entire song length could have different colours. The user 
> should be able to define e.g. the background colour from 1.00.000 to 
> 2.00.000 as red for the intro, from 2.00.000 to 3.01.123 as green for 
> the verse, from 3.01.123 to 4.00.000 as violet for the bridge, from 
> 4.00.000 to 8.00.000 as yellow for the refrain and so on.
> 

that sounds like custom location markers. besides tempo/time-signature
changes, location markers are still missing implementation, long overdue,
buried deep in the creepy TODO-pile :)


cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Qtractor-devel] [ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild!

[Rui N. C. <rn...@rn...>]

What? No automation, yet?

Yes I failed the promise once again. So what? What would you expect from
this self-called über-procrastinator? As sure is one to say that this is
the Year of Linux Desktop (YOLD:), I'll give you the shivers and command
this one will be the year of Qtractor Automation. No kiddin' ;)

Meanwhile, this new dot-release brings you several niceties, a couple of
them have been waaay longer and dustier on the all-mighty-overdue TODO
list than automation is. Rejoice! or else...

  Qtractor 0.4.4 (frisky demivierge) is in the wild!

Release highlights:

  * LV2 plug-in support (NEW)
  * MIDI event list view (NEW)
  * Expedite audio/MIDI clip import (NEW)
  * DSSI plug-in output control ports feedback/update (NEW)
  * JACK transport, MMC, SPP control options (NEW)
  * Self-bounce/recording (FIX)
  * Audio/MIDI drift correction (FIX)
  * Anti-glitch audio micro-fade-in/out ramp smoothing (FIX)

Website:

  http://qtractor.sourceforge.net

Project page:

  http://sourceforge.net/projects/qtractor

Downloads:

- source tarball:
  http://downloads.sourceforge.net/qtractor/qtractor-0.4.4.tar.gz

- source package (openSUSE 11.2):

http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.src.rpm

- binary packages (openSUSE 11.2):

http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.i586.rpm

http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.x86_64.rpm

- binary packages (Ubuntu 8.04 LTS; no LV2 support):

http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_i386.deb

http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_amd64.deb

- binary packages (Ubuntu 9.10):

http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_i386.deb

http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_amd64.deb

- user manual (ever still outdated):
  http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf

Weblog (upstream support):

  http://www.rncbc.org

License:

  Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.

Change-log:

- For all the DSSI plugins that have output control ports, a host
feedback/update process cycle is now being finally provided: all output
control ports are now marshaled to their respective GUI process, rather
often and when found open/visible.

- MIDI clip editor (aka piano-roll) snap-to-beat behavior on edit mode
is now kind of more like 'filling-in-the-blanks' (as Frank Neumann et
al. wishes ;)

- Fixed MIDI clip editor mistake when reverting to initial clip length,
before closing and discard changes (thanks to Frank Neumann, for
spotting this one).

- LADISH Level 1 support has been added: SIGUSR1 signal trap just makes
it a shortcut to File/Save.

- Avoid parameter value flickering, due to duplicate command invocation,
most evident when changing values massively on native Linux VSTi plugin
editor GUIs (thanks to a detailed report on this odd behavior, from Mike
of linuxDSP.co.uk).

- Another TODO item bites the dust: MIDI event list editor, now
accessible from the MIDI clip editor menu (View/Events)

- Last used session directory is now made current on startup only when
no filename is given on the command line (solving bug #2920244).

- Current snap-to-beat setting (time quantization) now affects the
anchor event only, while dragging, moving and/or pasting multiple events
over the MIDI clip editor (aka piano-roll).

- Make anti-glitch audio clip micro fade-in/outs independent from
current buffer size as much as possible.

- Audio/MIDI engine drift correction gets really sophisticated, with the
help of (now old) ALSA MIDI tempo skew facility.

- Edit/Clip/Import... menu option is now available for expedite clip
insertion from audio and MIDI file requesters.

- Set default session directory effective to file's location.

- Audio track/clip recording process has been target to special
re-factorization across the internal audio engine process cycle, in a
late attempt to get self-bounce/recording effective and working
consistently for all track layouts.

- All session related dialogs are now set to window modality, (were set
to default application modality before) allowing for continued input
focus and interaction on all plugin/tool windows.

- An off-by-one nasty old bug fixed in audio clip drawing, was causing
instant crashes on certain zoom levels of the main track view.

- Graphical MIDI clip representation regarding note/pitch range is now
kept as much as possible across clip edits (cut, copy, paste, drag,
move, delete, etc.)

- LV2 plug-in hosting has finally come into actual implementation; only
some and the most basic LV2 plug-in features are supported at the
moment; probably there's no big advantage against the old LADSPA ones;
there's some support for external UIs though; also, LV2 MIDI/Event
bare-bones support is included but chances are it won't build nor work
right on most of the setups out there. It's a WIP host implementation
anyways, as is the whole LV2 spec. for that matter ;)

- Connections filter is now reset when widget is shown through the
View/Connections main menu or toolbar button.

- Audio bus auto-connection option is now applied when creating or
updating, newer or existing buses, respectively.

- Global configuration state is now explicitly saved/committed to disk
whenever View/Options... dialog changes are applied or when a session is
loaded or saved.

- Audio ramping spin-locking makes its smooth stuff, in an attempt to
reduce glitching and crackling when editing (due to its own pseudo
spin-locking) and toggling playback states.

- JACK Transport, MMC Device, and MIDI Song Position pointer (SPP)
control modes are now made optional (View/Options...), allowing for
discretionary configuration: None/Disabled, Slave/Input, Master/Output
or Full/Duplex (default).

- Session files may now be dragged and dropped over the main track view
and get loaded for business as usual (once quietly ignored).

- In an attempt to mitigate potential stack corruption and sudden
crashes, old commented out session pseudo-locks are now back in business
while executing clip editing commands (cut, paste, drag, move, insert,
delete) and playback is currently rolling.

- Adjusted first-time application window size to fit into 800x600 screen
size and with reasonable initial dock-ables layout.

- Avoid duplicate snap-to-grid effect when changing the length of MIDI
clip editor events across non-zero clip offsets (after a glitch reported
by Ralf Mardorf).

- Late audio track processing optimization, suppressing all plugin,
mixer and monitor pass-through activity when given track is muted,
either explicitly or implicitly (ie. other track is in solo state).

- Entering System Exclusive events (SysEx) on the MIDI clip editor (aka
matrix/piano-roll widget), yet something not fully supported anyway,
even though allowed in edit mode, doesn't crash the whole damn thing
anymore, while saving the clip to a file.

- Strict aliasing avoidance, with plain and demanded use of 'union', as
much as to stop nagging warnings from gcc >= 4.4.1 (last seen on
src/qtractorMidiEvent.h hackery).

- Visual correct play-head position while changing zoom levels,
applicable to both main track and MIDI clip editor views.


Cheers && Enjoy.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] release 0.4.4 ready ?

[Rui N. C. <rn...@rn...>]

On 01/16/2010 02:47 PM, Frank Neumann wrote:
> 
> Hi list,
> On Sat, 16 Jan 2010 12:09:34 +0000
> Rui Nuno Capela <rn...@rn...> wrote:
> 
>> i believe current svn trunk (qtractor 0.4.3.1493) is ready as for (dot)
>> release...
>>
>> if any of you know of any show-stopper, please tell it now! :)
> 
> In some MIDI editing sessions during the last days, I stumbled over a few small
> "irregularities" that I still need to reproduce safely before pestering you
> with that, but I think from my point of view it's at least a "best so far"
> version, so go ahead..
> 

i tend to take dot-releases as baselines. never thought of it being
"perfect" :) i asked for show-stoppers, i guess "irregularities" don't
count ;)


> Maybe one quick feature question/request that deals with one of the recently
> added features: In the new Event list, it would be nice to display the start
> time of an event not / not only in hh:mm:ss.millis, but also in something like
> "bar:beat:miditicks". Is that already possible (configurable somewhere?), or
> could it be added so you can choose between those two time formats? I feel that
> bar:beat:tick is more important to a musician that the real time value..
> This also allows to quickly see if a note is really snapped correctly to a,
> say, 16th note. I currently suspect a snapping problem here (yet unconfirmed).
> 

you can set the time display format globally, see
View/Options.../Display/Time format, or from context-menu of the main
green-on-black transport time widget (right-click on it!) on main window
toolbar.

the time format seeting will affect all displayable times everywhere,
including in the midi clip editor event list.

byee
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Qtractor-devel] PS: Still 1488, but it might be the same for 1493

[Ralf M. <ral...@al...>]

Sometimes after deleting a note, there were some unneeded GUI elements 
shown (opened?) and most of the times the editor don't stay at the bar, 
but displays the end of the clip (this happened most of the times when 
deleting notes). I had trouble with the volume for a track. The fader 
was ignored after starting a session. I had to move the fader and to 
turn it back to the wanted position, before it takes effect. Qtractor 
also crashed sometimes, maybe there's still a fluidsynth DSSI issue or a 
problem with JACK on my hardware. You remember, I only can use JACK2, 
because JACK1 will disconnect audio clients all the time. I can't say 
anything about the crashes, I made music and didn't do a debugging ;).

Re: [Qtractor-devel] release 0.4.4 ready ?

[Ralf M. <ral...@al...>]

Rui Nuno Capela wrote:
> ppl
>
> i believe current svn trunk (qtractor 0.4.3.1493) is ready as for (dot)
> release...
>
> if any of you know of any show-stopper, please tell it now! :)
>
> cheers

Hi Rui :)

I'll upgrade from 1488 to 0.4.3.1493 in some minutes ;).
On the weekend I guess I'll make music. Perhaps you can wait until 
Monday (or a few hours, I need to go shopping, but I guess I'll make 
music today)?
For 1488 there are some issues, but only one is worth mentioning. 
Sometimes a track changes its name to the name of a clip on this track. 
I guess this happens sometimes when copying clips.
For the future I would like to have a better view for layered clips, to 
avoid minimal, unwanted layers. "Unwanted" layered clips aren't a 
problem in general, but when there is trouble, e.g. because of a bug for 
the snap in, it can become a problem.

Cheers,
Ralf

Re: [Qtractor-devel] release 0.4.4 ready ?

[Frank N. <bea...@we...>]

Hi list,
On Sat, 16 Jan 2010 12:09:34 +0000
Rui Nuno Capela <rn...@rn...> wrote:

> i believe current svn trunk (qtractor 0.4.3.1493) is ready as for (dot)
> release...
> 
> if any of you know of any show-stopper, please tell it now! :)

In some MIDI editing sessions during the last days, I stumbled over a few small
"irregularities" that I still need to reproduce safely before pestering you
with that, but I think from my point of view it's at least a "best so far"
version, so go ahead..

Maybe one quick feature question/request that deals with one of the recently
added features: In the new Event list, it would be nice to display the start
time of an event not / not only in hh:mm:ss.millis, but also in something like
"bar:beat:miditicks". Is that already possible (configurable somewhere?), or
could it be added so you can choose between those two time formats? I feel that
bar:beat:tick is more important to a musician that the real time value..
This also allows to quickly see if a note is really snapped correctly to a,
say, 16th note. I currently suspect a snapping problem here (yet unconfirmed).

Greetings, and thanks for all your work,
Frank

[Qtractor-devel] release 0.4.4 ready ?

[Rui N. C. <rn...@rn...>]

ppl

i believe current svn trunk (qtractor 0.4.3.1493) is ready as for (dot)
release...

if any of you know of any show-stopper, please tell it now! :)

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] DSSI Plugin on audio track mono, and some other (more DSSI specific) questions

[Mathias K. <mat...@we...>]

Rui Nuno Capela wrote:
> On 01/15/2010 05:19 PM, Mathias Krause wrote:
>   
>> [snip]
>>     
>>> homework done. svn trunk has it (qtractor-0.4.3.1489+):
>>>
>>> - For all the DSSI plugins that have output control ports,
>>>   a host feedback/update process cycle is now being finally
>>>   provided: all output control ports are now marshaled to
>>>   their respective GUI process, rather often and when found
>>>   open/visible.
>>>
>>> seeya
>>>   
>>>       
>> Hey Rui ...
>>
>> again ... that was fast. Cool ... in this case i will continue with
>> plugin-writing and tell you my findings...
>>
>> Another short question:
>> Is midi data also sent to the GUI by qtractor? Or is it only sent to the
>> plugin itself? I think, for the CALF monosynth, they do all the GUI by
>> receiving the midi data ... but i am not completely shure as the code is
>> very very distributed over several source files...
>>
>>     
>
> i'm sure all midi must go through dssi->run_synth()
>   
yeah ... but i wanted to know, if the events are also sent to the GUI 
... with OSC midi messages ...

> nb. calf plugins have this busy-loop that keeps sending "configure"
> feedback to host, which just smells like it's hacking around the dssi
> gui shortcomings, whatever, and might be its own dogfood (in
> jackcalfhost, i think)
>   
ah okay ... that's another version to do it ... hm ... not the best one 
... maybe

regards
mathias

Re: [Qtractor-devel] DSSI Plugin on audio track mono, and some other (more DSSI specific) questions

[Rui N. C. <rn...@rn...>]

On 01/15/2010 05:19 PM, Mathias Krause wrote:
> [snip]
>> homework done. svn trunk has it (qtractor-0.4.3.1489+):
>>
>> - For all the DSSI plugins that have output control ports,
>>   a host feedback/update process cycle is now being finally
>>   provided: all output control ports are now marshaled to
>>   their respective GUI process, rather often and when found
>>   open/visible.
>>
>> seeya
>>   
> Hey Rui ...
> 
> again ... that was fast. Cool ... in this case i will continue with
> plugin-writing and tell you my findings...
> 
> Another short question:
> Is midi data also sent to the GUI by qtractor? Or is it only sent to the
> plugin itself? I think, for the CALF monosynth, they do all the GUI by
> receiving the midi data ... but i am not completely shure as the code is
> very very distributed over several source files...
> 

i'm sure all midi must go through dssi->run_synth()

nb. calf plugins have this busy-loop that keeps sending "configure"
feedback to host, which just smells like it's hacking around the dssi
gui shortcomings, whatever, and might be its own dogfood (in
jackcalfhost, i think)

beware >:]
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] DSSI Plugin on audio track mono, and some other (more DSSI specific) questions

[Mathias K. <mat...@we...>]

[snip]
> homework done. svn trunk has it (qtractor-0.4.3.1489+):
>
> - For all the DSSI plugins that have output control ports,
>   a host feedback/update process cycle is now being finally
>   provided: all output control ports are now marshaled to
>   their respective GUI process, rather often and when found
>   open/visible.
>
> seeya
>   
Hey Rui ...

again ... that was fast. Cool ... in this case i will continue with 
plugin-writing and tell you my findings...

Another short question:
Is midi data also sent to the GUI by qtractor? Or is it only sent to the 
plugin itself? I think, for the CALF monosynth, they do all the GUI by 
receiving the midi data ... but i am not completely shure as the code is 
very very distributed over several source files...

regards,
mathias

Re: [Qtractor-devel] 0.4.3.1488 was: Re: There's a bug for 0.4.3.1487 for the clip snapping

[Rui N. C. <rn...@rn...>]

On 01/13/2010 09:58 PM, Rui Nuno Capela wrote:
> On 01/13/2010 09:16 PM, Ralf Mardorf wrote:
>> Ralf Mardorf wrote:
>>> Ralf Mardorf wrote:
>>>   
>>>> Hi :)
>>>>
>>>> today there really is a bug.
>>>>
>>>> I've got two clips for the bass.
>>>> The first one is from 2.01.000 to 4.01.000 and the second is from 
>>>> 4.01.000 to 6.01.000.
>>>> I copy those bass clips from 2.01.000 to 6.01.000 and try to paste 
>>>> them to 6.01.000.
>>>> "Snap/beat" is set to "Beat", but the first copied clip is from 
>>>> 5.04.955 to 7.04.955, followed by the second copied clip from 7.04.955 
>>>> to 9.04.955.
>>>> Using the clip properties I can add 5 ticks to the start points of the 
>>>> clips, doing this they are as wanted from 6.01.000 to 10.01.000.
>>>>     
>>>
>>> If I chose "Beat/3" instead of "Beat" for "Snap/beat", than the clips 
>>> will snap into the correct position. It's a triplet song, but a "beat" 
>>> is a "beat" is a ... for "triplet" and non-"triplet". Phew, now I can go 
>>> on with the song :).
>>>
>>> Ralf
>>
>> No, it doesn't work all the time. After copying the clips they are on a 
>> wrong position, e.g. 16 ticks beside. Moving them with the mouse a 
>> second time, they snap into the correct position.
>>
> 
> hmmm... i think i know this problem... it was subject of some "fix" a
> few weeks ago, guess that what's one calls a "short blanket syndrome",
> you fix on one side, it breaks on the other side :(
> 
> will try to reproduce this behavior, having handy the recent changes
> made to the midi clip editor, codename "filling in the blanks" ;)
> 

think i got this one. let's hope i did not pull the blanket way too much
to the side ;) qtractor-0.4.3.1490+ is svn trunk now:

- Make sure snap/beat is effective when pasting clips on main track-view
(REGRESSION).

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] DSSI Plugin on audio track mono, and some other (more DSSI specific) questions

[Rui N. C. <rn...@rn...>]

On 01/12/2010 10:00 PM, Rui Nuno Capela wrote:
> On 01/12/2010 06:19 PM, Mathias Krause wrote:
>>
>>>> 3. My plugin has some control ports, and they all seem to work fine. But 
>>>> i do need a control port output at the plugin, so that a response can be 
>>>> sent to the plugin gui (which is also started fine by qtractor). So i 
>>>> created a control port as output of the plugin. Now, when i change the 
>>>> data of this port from within the plugin, the GUI and qtractor do not 
>>>> recognize that the value has changed. Do you know if there's such a 
>>>> mechanism?
>>>
>>> hmmm... now that you speak, there may be an issue regarding dssi output
>>> ports--unlike the newer lv2--dssi output control ports are not being
>>> marshalled to the gui. in fact, they are being just ignored. i guess, no
>>> one (ie. me:) has ever found the need to date, so i never implemented it :o)
>>>   
>> hm ... only this problem is remaining. How can i send some information 
>> from the plugin code to the gui. Unfortunately the plugin is not really 
>> useable without the GUI feedback.
>>
> 
> problem here is that qtractor as a ladspa/dssi host is connecting all
> output control ports into the void. i will address this issue asap. stay
> tuned ;)
> 
>> How is that solved for the Calf Monosynth Dssi? I can see the filter 
>> changing, when i play a note.
>> Maybe, the GUI only does receive the MIDI information and then calculate 
>> it's own GUI events?
>>
>> I think, i am not able to use a input port, and set it directly from my 
>> plugin code!?
>>
> 
> good question. one could look at the source but i guess the gui is
> having a peek on the plugin descriptor and read from the input data
> ports directly. hmmm...
> 
> 
>> Is there any other method, to send some data from the plugin to it's GUI ?
>>
> 
> for an out-of-process gui, as in a dssi gui, i would say there isn't.
> but then again, one has to investigate which magic tricks are the calf
> plugins using ...
> 
>> For better understanding. My plugin does a FFT for the incoming audio 
>> data, and the result of that FFT (only one (some) integer number (s)) 
>> has to be used in the GUI for making some visualization of what is 
>> happening after the FFT as this is a kind of pitch correction (or pitch 
>> changing).
>>
> 
> will do my homework re. ladspa & dssi output control ports ...
> 

homework done. svn trunk has it (qtractor-0.4.3.1489+):

- For all the DSSI plugins that have output control ports,
  a host feedback/update process cycle is now being finally
  provided: all output control ports are now marshaled to
  their respective GUI process, rather often and when found
  open/visible.

seeya
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] 0.4.3.1488 was: Re: There's a bug for 0.4.3.1487 for the clip snapping

[Rui N. C. <rn...@rn...>]

On 01/13/2010 09:16 PM, Ralf Mardorf wrote:
> Ralf Mardorf wrote:
>> Ralf Mardorf wrote:
>>   
>>> Hi :)
>>>
>>> today there really is a bug.
>>>
>>> I've got two clips for the bass.
>>> The first one is from 2.01.000 to 4.01.000 and the second is from 
>>> 4.01.000 to 6.01.000.
>>> I copy those bass clips from 2.01.000 to 6.01.000 and try to paste 
>>> them to 6.01.000.
>>> "Snap/beat" is set to "Beat", but the first copied clip is from 
>>> 5.04.955 to 7.04.955, followed by the second copied clip from 7.04.955 
>>> to 9.04.955.
>>> Using the clip properties I can add 5 ticks to the start points of the 
>>> clips, doing this they are as wanted from 6.01.000 to 10.01.000.
>>>     
>>
>> If I chose "Beat/3" instead of "Beat" for "Snap/beat", than the clips 
>> will snap into the correct position. It's a triplet song, but a "beat" 
>> is a "beat" is a ... for "triplet" and non-"triplet". Phew, now I can go 
>> on with the song :).
>>
>> Ralf
> 
> No, it doesn't work all the time. After copying the clips they are on a 
> wrong position, e.g. 16 ticks beside. Moving them with the mouse a 
> second time, they snap into the correct position.
> 

hmmm... i think i know this problem... it was subject of some "fix" a
few weeks ago, guess that what's one calls a "short blanket syndrome",
you fix on one side, it breaks on the other side :(

will try to reproduce this behavior, having handy the recent changes
made to the midi clip editor, codename "filling in the blanks" ;)

byee
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] 0.4.3.1488 was: Re: There's a bug for 0.4.3.1487 for the clip snapping

[Ralf M. <ral...@al...>]

Ralf Mardorf wrote:
> Ralf Mardorf wrote:
>   
>> Hi :)
>>
>> today there really is a bug.
>>
>> I've got two clips for the bass.
>> The first one is from 2.01.000 to 4.01.000 and the second is from 
>> 4.01.000 to 6.01.000.
>> I copy those bass clips from 2.01.000 to 6.01.000 and try to paste 
>> them to 6.01.000.
>> "Snap/beat" is set to "Beat", but the first copied clip is from 
>> 5.04.955 to 7.04.955, followed by the second copied clip from 7.04.955 
>> to 9.04.955.
>> Using the clip properties I can add 5 ticks to the start points of the 
>> clips, doing this they are as wanted from 6.01.000 to 10.01.000.
>>     
>
> If I chose "Beat/3" instead of "Beat" for "Snap/beat", than the clips 
> will snap into the correct position. It's a triplet song, but a "beat" 
> is a "beat" is a ... for "triplet" and non-"triplet". Phew, now I can go 
> on with the song :).
>
> Ralf

No, it doesn't work all the time. After copying the clips they are on a 
wrong position, e.g. 16 ticks beside. Moving them with the mouse a 
second time, they snap into the correct position.

[Qtractor-devel] 0.4.3.1488 was: Re: There's a bug for 0.4.3.1487 for the clip snapping

[Ralf M. <ral...@al...>]

Ralf Mardorf wrote:
> Hi :)
>
> today there really is a bug.
>
> I've got two clips for the bass.
> The first one is from 2.01.000 to 4.01.000 and the second is from 
> 4.01.000 to 6.01.000.
> I copy those bass clips from 2.01.000 to 6.01.000 and try to paste 
> them to 6.01.000.
> "Snap/beat" is set to "Beat", but the first copied clip is from 
> 5.04.955 to 7.04.955, followed by the second copied clip from 7.04.955 
> to 9.04.955.
> Using the clip properties I can add 5 ticks to the start points of the 
> clips, doing this they are as wanted from 6.01.000 to 10.01.000.

If I chose "Beat/3" instead of "Beat" for "Snap/beat", than the clips 
will snap into the correct position. It's a triplet song, but a "beat" 
is a "beat" is a ... for "triplet" and non-"triplet". Phew, now I can go 
on with the song :).

Ralf

Re: [Qtractor-devel] It would be nice to have a Qtractor version named by something from the Bikini Bottom Universe - was: Re: MIDI note snapping

[Ralf M. <ral...@al...>]

Rui Nuno Capela wrote:
> however, i was referring to the physical properties of a sponge and its effect on liquids ;)
>   

Hm, smoke from the Netherlands can reduce the effect to absorb liquids 
:)<~ , side effects might be comparable ;).
I'm frustrated because of trouble with tuxguitar and qtractor. I've 
given up using tuxguitar now. I'll take a walk without smoke and liquids 
and using qtractor I'll try to continue my song later. Listening to what 
I composed while fighting software issues I'm afraid that my song is and 
will be crap.

Next time I'll keep a package for a stable version of qtractor, when I 
install latest SVN trunk.

Cheers,
Ralf

[Qtractor-devel] There's a bug for 0.4.3.1487 for the clip snapping

[Ralf M. <ral...@al...>]

Hi :)

today there really is a bug.

I've got two clips for the bass.
The first one is from 2.01.000 to 4.01.000 and the second is from 
4.01.000 to 6.01.000.
I copy those bass clips from 2.01.000 to 6.01.000 and try to paste them 
to 6.01.000.
"Snap/beat" is set to "Beat", but the first copied clip is from 5.04.955 
to 7.04.955, followed by the second copied clip from 7.04.955 to 9.04.955.
Using the clip properties I can add 5 ticks to the start points of the 
clips, doing this they are as wanted from 6.01.000 to 10.01.000.
The problem still is that I've got a lot of other clips to copy and 
using the clip properties is to time consuming and needs too much attention.

Not a bug, but also something that IMO needs a fix is editing start 
points for notes.
I've got a clip for a nylon guitar sample. I start composing playing my 
real nylon guitar and after that I don't record the guitar by using my 
cheap dynamical microphone, but I edit real guitar chords as MIDI note 
events.
Playing those edited notes quantised or moved by using the "Randomize" 
options, the guitar sample doesn't sound realistic. It sounds more 
smooth if some notes can be moved by just two ticks, but this is nearly 
impossible. Using "None" as grid isn't comfortable, because of the mouse 
resolution and even "Beat/48" isn't subtle enough.
Anyway, this issue isn't something I really need today, but I need a 
version of Qtractor without the bug for the clips.

Unfortunately I only have those versions:

spinymouse-sudo@64studio:/usr/src/qtractor$ ls -l qtractor_*
-rw-r--r-- 1 root src 1002398 2010-01-11 22:43 qtractor_0.4.3-1486_amd64.deb
-rw-r--r-- 1 root src 1002486 2010-01-12 16:57 qtractor_0.4.3-1487_amd64.deb

I expect that 1486 has got the same bug. The current SVN version is 
1488. Reading the change log I expect that this version has got the bug too.
I'll test this versions, but has anybody the source for an older (not to 
old ;) version or a Hardy 64bit package?

Cheers,
Ralf

Re: [Qtractor-devel] DSSI Plugin on audio track mono, and some other (more DSSI specific) questions

[Rui N. C. <rn...@rn...>]

On 01/12/2010 06:19 PM, Mathias Krause wrote:
> 
>>> 3. My plugin has some control ports, and they all seem to work fine. But 
>>> i do need a control port output at the plugin, so that a response can be 
>>> sent to the plugin gui (which is also started fine by qtractor). So i 
>>> created a control port as output of the plugin. Now, when i change the 
>>> data of this port from within the plugin, the GUI and qtractor do not 
>>> recognize that the value has changed. Do you know if there's such a 
>>> mechanism?
>>
>> hmmm... now that you speak, there may be an issue regarding dssi output
>> ports--unlike the newer lv2--dssi output control ports are not being
>> marshalled to the gui. in fact, they are being just ignored. i guess, no
>> one (ie. me:) has ever found the need to date, so i never implemented it :o)
>>   
> hm ... only this problem is remaining. How can i send some information 
> from the plugin code to the gui. Unfortunately the plugin is not really 
> useable without the GUI feedback.
> 

problem here is that qtractor as a ladspa/dssi host is connecting all
output control ports into the void. i will address this issue asap. stay
tuned ;)

> How is that solved for the Calf Monosynth Dssi? I can see the filter 
> changing, when i play a note.
> Maybe, the GUI only does receive the MIDI information and then calculate 
> it's own GUI events?
> 
> I think, i am not able to use a input port, and set it directly from my 
> plugin code!?
> 

good question. one could look at the source but i guess the gui is
having a peek on the plugin descriptor and read from the input data
ports directly. hmmm...


> Is there any other method, to send some data from the plugin to it's GUI ?
> 

for an out-of-process gui, as in a dssi gui, i would say there isn't.
but then again, one has to investigate which magic tricks are the calf
plugins using ...

> For better understanding. My plugin does a FFT for the incoming audio 
> data, and the result of that FFT (only one (some) integer number (s)) 
> has to be used in the GUI for making some visualization of what is 
> happening after the FFT as this is a kind of pitch correction (or pitch 
> changing).
> 

will do my homework re. ladspa & dssi output control ports ...

seeya
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] It would be nice to have a Qtractor version named by something from the Bikini Bottom Universe - was: Re: MIDI note snapping

[Rui N. C. <rn...@rn...>]

On 01/12/2010 07:24 PM, Ralf Mardorf wrote:
> Rui Nuno Capela wrote:
>> be prepared. when i'm not with my wife and kid, "spongebob" is my middle
>> name (without the square pants:)
>>   
> 
> Why should Frank be prepared? In Germany Spongebob is a more respected
> hero, but idiot.
> Do you know the episode "The Paper"?
> "Squidward throws a bubble gum wrapper on SpongeBob's lawn. When
> SpongeBob discovers it, he asks Squidward if he can keep it. Squidward,
> who sees the paper as a worthless pile of junk, says yes. Spongebob asks
> him several more times to make sure that he doesn't want it, and
> Squidward assures him that he has no use for the paper, and
> saracstically makes him promise to never give it back. SpongeBob uses
> his imagination to have fun and do amazing things with the paper, and
> Squidward becomes jealous and attempts to take it back."
> (http://spongebob.wikia.com/wiki/The_Paper)
> 

i know the cartoon and my kid loves it and, guess what, he prefers the
german version from nick.de than the portuguese spoken one, go figure :)

however, i was referring to the physical properties of a sponge and its
effect on liquids ;)


> It would be nice to have a Qtractor version, maybe 0.4.4, named by
> something from the Bikini Bottom Universe.

sorry again, the codename of the next 0.4.4 release is already chosen
and it still follows the f&d initials. surprise surprise :)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Qtractor-devel] It would be nice to have a Qtractor version named by something from the Bikini Bottom Universe - was: Re: MIDI note snapping

[Ralf M. <ral...@al...>]

Rui Nuno Capela wrote:
> be prepared. when i'm not with my wife and kid, "spongebob" is my middle
> name (without the square pants:)
>   

Why should Frank be prepared? In Germany Spongebob is a more respected 
hero, but idiot.
Do you know the episode "The Paper"?
"Squidward throws a bubble gum wrapper on SpongeBob's lawn. When 
SpongeBob discovers it, he asks Squidward if he can keep it. 
Squidward, who sees the paper as a worthless pile of junk, says yes. 
Spongebob asks him several more times to make sure that he doesn't want 
it, and Squidward assures him that he has no use for the paper, and 
saracstically makes him promise to never give it back. SpongeBob uses 
his imagination to have fun and do amazing things with the paper, and 
Squidward becomes jealous and attempts to take it back." 
(http://spongebob.wikia.com/wiki/The_Paper)

It would be nice to have a Qtractor version, maybe 0.4.4, named by 
something from the Bikini Bottom Universe.

Re: [Qtractor-devel] MIDI note snapping

[Rui N. C. <rn...@rn...>]

On 01/12/2010 05:17 PM, Frank Neumann wrote:
> 
> Hi list,
> 
>>> nb. currently, /that/ relative distance is exactly 1/2 of a "cell" ie.
>>> middle. clicking on the left middle will snap to current cell, right of
>>> middle will snap to "next cell".
>>>
>>> i would consider 1/8 or 1/16 a good enough "attractive factor" :)  
>>>
>>
>>
>> make it 1/256 (power of 2 love ftw:)
>>
>> svn trunk has it now (qtractor 0.4.3.1487+)
>>
>> test && tell
> 
> Thank you, master. Much better now :-). Really appreciated.
> 
> yours.LAC_Utrecht....oh well, I am repeating myself. If you come there, it's
> perhaps going to get..funny :-).
> 

be prepared. when i'm not with my wife and kid, "spongebob" is my middle
name (without the square pants:)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Qtractor-devel] MIDI note snapping

[Ralf M. <ral...@al...>]

Frank Neumann wrote:
> Hi list,
>
>   
>>> nb. currently, /that/ relative distance is exactly 1/2 of a "cell" ie.
>>> middle. clicking on the left middle will snap to current cell, right of
>>> middle will snap to "next cell".
>>>
>>> i would consider 1/8 or 1/16 a good enough "attractive factor" :)  
>>>
>>>       
>> make it 1/256 (power of 2 love ftw:)
>>
>> svn trunk has it now (qtractor 0.4.3.1487+)
>>
>> test && tell
>>     
>
> Thank you, master. Much better now :-). Really appreciated.
>
> yours.LAC_Utrecht....oh well, I am repeating myself. If you come there, it's
> perhaps going to get..funny :-).
>
> Greetings,
> Frank

Utrecht is only a stone's throw from my home town Oberhausen, 151.94 km, 
but don't worry, it's much too far away for me to hold up the Linux 
audio community :D.