Re: [proteowizard-developer] PWIZ / SPC converters integration

[Joshua T. <jt...@sy...>]

Hi Matt, thanks, and I'll take a look!  Agreed, the Waters DAC is
painfully slow, especially for MRM since they store each transition as
a scan.  We've been talking with a friendly software contact at
Waters, and they are aware of the issues, but probably nothing is
going to happen.  Maybe down the road they'll be more motivated if
they get on board with PWIZ :)

Josh


On Fri, Jul 11, 2008 at 1:38 PM, Matthew Chambers
<mat...@va...> wrote:
> Hi Josh,
>
> I just committed Reader_Waters and friends to the repository. You'll notice
> big snippets of MassLynxInterface in there, but I definitely did a lot of
> refactoring. :) It's fine of course to still have it be LGPL licensed.
>
> Hopefully it's a very /good/ "simple demo example." :)
>
> DAC is bloody slow. It could have a race with Analyst to see which can
> access data the slowest! ;) I got rid of most of the function preprocessing
> (which I assume was intended to allow sorting the spectrum list in retention
> time order?) because it was way too time intensive to do when opening the
> file. I also switched to using the "property" style interface in DAC since I
> could just use those directly in the CVParam::set() calls.
>
> -Matt
>
>
> Joshua Tasman wrote:
>>
>> (sorry all, I started replying to Matt only accidently)
>>
>>
>> Yes, it would be nice to have this determined algorithmically, but I
>> haven't done any work on this.  Anyone is welcome to work on this
>> problem-- ideally once the initial code merge is complete and working
>> exactly the same as the current version.
>>
>> So, Matt-- are you rewriting the SPC converter on my behalf and
>> checking into the LGPL code, or is this just a simple demo example?
>> My personal preference would have been to check in the full working
>> SPC mzXML branch as-is first, so that the changes and modifications
>> can be tracked.
>>
>> I don't have a formal test set for these but can get these together.
>>
>> Josh
>>
>>
>> On Mon, Jul 7, 2008 at 11:19 AM, Matthew Chambers
>> <mat...@va...> wrote:
>>
>>>
>>> Damn, that is terrible. Have you pondered using heuristics to determine
>>> them
>>> automatically? Also, what test data do you have (i.e. at lease one for
>>> each
>>> case) and is it publicly available?
>>>
>>> -Matt
>>>
>>>
>>> Joshua Tasman wrote:
>>>
>>>>
>>>> Hi Matt,
>>>>
>>>> This info is not present in the DAC interface.
>>>>
>>>> -Josh
>>>>
>>>> On Mon, Jul 7, 2008 at 8:26 AM, Matthew Chambers
>>>> <mat...@va...> wrote:
>>>>
>>>>
>>>>>
>>>>> Hi Josh,
>>>>>
>>>>> I'm trying to convert MassLynxInterface to Reader_Waters in pwiz (as an
>>>>> example) because it's much more compact than the
>>>>> Analyst[QS][1.1|1.5|2.0]Interfaces of mzWiff, but I've got some
>>>>> questions
>>>>> about the interface. Ideally the flags --nolockspray and --MSe could be
>>>>> eliminated (and the conversion logic simplified even more so) if the
>>>>> DAC
>>>>> interface can provide that information. Is that not possible?
>>>>>
>>>>> -Matt
>>>>>
>>>>>
>>>>> Darren Kessner wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Matt or I will be creating a skeleton project in pwiz_aux/isb/readers
>>>>>> to
>>>>>> get the ball rolling.
>>>>>>
>>>>>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> proteowizard-developer mailing list
>> pro...@li...
>> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>>
>